要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
分享到
OO设计的LSP里氏替换原则
 

作者:Eric_Jo,发布于2011-12-19

 

概要

Functionsthatusepointersorreferencestobaseclassesmustbeabletouseobjectsofderivedclasseswithoutknowingit.

所有引用基类的地方必须能透明地使用其子类的对象。

即:

  • 所以使用基类代码的地方,用派生类代码替换后,能够正确的执行动作处理。
  • 换句话说,如果派生类替换了基类后,不能够正确执行动作,那么他们的继承关系就应该废除。

换个说法,只有满足以下2个条件的OO设计才可被认为是满足了LSP原则:

  • 不应该在代码中出现if/else之类对子类类型进行判断的条件。以下代码就违反了LSP定义。

if(objtypeofClass1){

    dosomething

}elseif(objtypeofClass2){

    dosomethingelse

}

  • 子类应当可以替换父类并出现在父类能够出现的任何地方,

或者说如果我们把代码中使用基类的地方用它的子类所代替,代码还能正常工作。

里氏替换原则LSP是使代码符合开闭原则的一个重要保证。同时LSP体现了:

  • 类的继承原则:如果一个继承类的对象可能会在基类出现的地方出现运行错误,
  • 则该子类不应该从该基类继承,或者说,应该重新设计它们之间的关系。
  • 动作正确性保证:从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。

类的继承原则:

RobertC.Martin氏在介绍LiskovSubstitutionPrinciple(LSP)的原文里,举了Rectangle和Square的例子。

这里沿用这个例子,但用Java语言对其加以重写,并忽略了某些细节只列出下面的精要

部分来说明里氏替换原则对类的继承上的约束。

//代码:

classRectangle{

    doublewidth;

    doubleheight;

    publicdoublegetHeight(){

        returnheight;

    }

    publicvoidsetHeight(doubleheight){

        this.height=height;

    }

    publicdoublegetWidth(){

        returnwidth;

    }

    publicvoidsetWidth(doublewidth){

        this.width=width;

    }

}

classSquareextendsRectangle{

    publicvoidsetHeight(doubleheight){

        super.setHeight(height);

        super.setWidth(height);

    }

    publicvoidsetWidth(doublewidth){

        super.setHeight(width);

        super.setWidth(width);

    }

}

这里Rectangle是基类,Square从Rectangle继承。

这种继承关系有什么问题吗?

假如已有的系统中存在以下既有的业务逻辑代码:

voidg(Rectangler){

    r.setWidth(5);

    r.setHeight(4);

    if(r.getWidth()*r.getHeight()!=20){

        thrownewRuntimeException();

    }

}

则对应于扩展类Square,在调用既有业务逻辑时:

Rectanglesquare=newSquare();

g(square);

时会抛出一个RuntimeException异常。这显然违反了LSP原则。

动作正确性保证:

因为LSP对子类的约束,所以为已存在的类做扩展构造一个新的子类时,

根据LSP的定义,不会给已有的系统引入新的错误。

DesignbyContract

根据BertrandMeyer氏提出的DesignbyContract(DBC:基于合同的设计)概念的描述,

对于类的一个方法,都有一个前提条件以及一个后续条件,前提条件说明方法接受什么样的参数数据等,

只有前提条件得到满足时,这个方法才能被调用;同时后续条件用来说明这个方法完成时的状态,

如果一个方法的执行会导致这个方法的后续条件不成立,那么这个方法也不应该正常返回。

现在把前提条件以及后续条件应用到继承子类中,子类方法应该满足:

1)前提条件不强于基类.

2)后续条件不弱于基类.

换句话说,通过基类的接口调用一个对象时,用户只知道基类前提条件以及后续条件。

因此继承类不得要求用户提供比基类方法要求的更强的前提条件,

亦即,继承类方法必须接受任何基类方法能接受的任何条件(参数)。

同样,继承类必须顺从基类的所有后续条件,亦即,

继承类方法的行为和输出不得违反由基类建立起来的任何约束,不能让用户对继承类方法的输出感到困惑。

这样,我们就有了基于合同的LSP,基于合同的LSP是LSP的一种强化。

在很多情况下,在设计初期我们类之间的关系不是很明确,

LSP则给了我们一个判断和设计类之间关系的基准:需不需要继承,以及怎样设计继承关系。

总结

LSP:子类必须能够替换基类。

Subtypesmustbesubstitutable fortheirbasetypes.

1.LSP关注的是怎样良好的使用继承.

2.必须要清楚是使用一个Method还是要扩展它,但是绝对不是改变它。

3.LSP清晰的指出,OOD的IS-A关系是就行为方式而言,

   行为方式是可以进行合理假设的,是客户程序所依赖的。

4.LSP让我们得出一个重要的结论:一个模型如果孤立的看,并不具有真正意义的有效性。

   模型的有效性只能通过它的客户程序来表现。必须根据设计的使用者做出的合理假设来审视它。

   而假设是难以预测的,直到设计臭味出现的时候才处理它们。

5.对于LSP的违反也潜在的违反了OC


 
相关文章

UML建模之时序图
UML状态图
区分UML类图中的几种关系
UML建模之活动图介绍
 
相关文档

UML统一建模语言参考手册
网上商城UML图
UML建模示例:JPetStor
UML序列图编写规范
 
相关课程

UML与面向对象分析设计
UML + 嵌入式系统分析设计
业务建模与业务分析
基于UML和EA进行系统分析设计


如何向妻子解释OOD
OOAD与UML笔记
UML类图与类的关系详解
UML统一建模语言初学
总结一下领域模型的验证
基于 UML 的业务建模


面向对象的分析设计
基于UML的面向对象分析设计
UML + 嵌入式系统分析设计
关系数据库面向OOAD设计
业务建模与业务架构
使用用例进行需求管理

相关咨询服务
UML+OOAD项目实施
UML+OOAD项目敏捷咨询


某航空IT部门 业务分析与业务建模
联想 业务需求分析与建模
北京航管科技 EA工具与架构设计
使用EA和UML进行嵌入式系统分析
全球最大的茶业集团 UML系统分析
华为 基于EA的嵌入式系统建模
水资源服务商 基于EA进行UML建模
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号