OO设计的里氏替换原则

来源:互联网 发布:米妈淘宝联盟是真的吗 编辑:程序博客网 时间:2024/05/17 23:46

Liskov Substitution Principle (LSP) - OO设计的里氏替换原则

里氏替换原则LSP的概念解说

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
所有引用基类的地方必须能透明地使用其子类的对象。也就是说,只有满足以下2个条件的OO设计才可被认为是满足了LSP原则
- 不应该在代码中出现if/else之类对子类类型进行判断的条件。以下代码就违反了LSP定义。
if (obj typeof Class1) {
    do something
} else if (obj typeof Class2) {
    do something else
}
- 子类应当可以替换父类并出现在父类能够出现的任何地方,或者说如果我们把代码中使用基类的地方用它的子类所代替,代码还能正常工作。

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

类的继承原则:
Robert C. Martin氏在介绍Liskov Substitution Principle (LSP)的原文里,举了Rectangle和Square的例子。这里沿用这个例子,但用Java语言对其加以重写,并忽略了某些细节只列出下面的精要部分来说明 里氏替换原则 对类的继承上的约束。
代码:



这里Rectangle是基类,Square从Rectangle继承。
这种继承关系有什么问题吗?

假如已有的系统中存在以下既有的业务逻辑代码:
void g(Rectangle r) {
    r.setWidth(5);
    r.setHeight(4);
    if (r.getWidth() * r.getHeight() != 20) {
        throw new RuntimeException();
    }
}

则对应于扩展类Square,在调用既有业务逻辑时:
        Rectangle square = new Square();
        g(square);
时会抛出一个RuntimeException异常。这显然违反了LSP原则。


动作正确性保证:
因为LSP对子类的约束,所以为已存在的类做扩展构造一个新的子类时,根据LSP的定义,不会给已有的系统引入新的错误。

Design by Contract

根据Bertrand Meyer氏提出的Design by Contract(DBC:基于合同的设计)概念的描述,对于类的一个方法,都有一个前提条件以及一个后续条件,前提条件说明方法接受什么样的参数数据等,只有前提条件得到满足时,这个方法才能被调用;同时后续条件用来说明这个方法完成时的状态,如果一个方法的执行会导致这个方法的后续条件不成立,那么这个方法也不应该正常返回。
现在把前提条件以及后续条件应用到继承子类中,子类方法应该满足:
1)前提条件不强于基类.
2)后续条件不弱于基类.

换句话说,通过基类的接口调用一个对象时,用户只知道基类前提条件以及后续条件。因此继承类不得要求用户提供比基类方法要求的更强的前提条件,亦即,继承类方法必须接受任何基类方法能接受的任何条件(参数)。同样,继承类必须顺从基类的所有后续条件,亦即,继承类方法的行为和输出不得违反由基类建立起来的任何约束,不能让用户对继承类方法的输出感到困惑。
这样,我们就有了基于合同的LSP,基于合同的LSP是LSP的一种强化。

在很多情况下,在设计初期我们类之间的关系不是很明确,LSP则给了我们一个判断和设计类之间关系的基准:需不需要继承,以及怎样设计继承关系。


原创粉丝点击