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

发布时间：2020-05-23 03:41:13 所属栏目：程序设计来源：互联网

导读：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从 Object Menter得到。

本文介绍“Principles of OOD”中的里氏替换原则：Liskov Substitution Principle (LSP)。

可以从这里查看Liskov Substitution Principle (LSP)的原文。

里氏替换原则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语言对其加以重写，并忽略了某些细节只列出下面的精要部分来说明里氏替换原则对类的继承上的约束。
代码：

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);
}
}

class Rectangle {
double width;
double height;


public double getHeight() {
return height;
}
public void setHeight(double height) {
this.height = height;
}
public double getWidth() {
return width;
}
public void setWidth(double width) {
this.width = width;
} 
}

class Square extends Rectangle {
public void setHeight(double height) {
super.setHeight(height);
super.setWidth(height);
}

public void setWidth(double width) {
super.setHeight(width);
super.setWidth(width);
}
}

这里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：基于合同的设计）概念的描述，对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等，只有前提条件得到满足时，这个方法才能被调用；同时后续条件用来说明这个方法完成时的状态，如果一个方法的执行会导致这个方法的后续条件不成立，那么这个方法也不应该正常返回。现在把前提条件以及后续条件应用到继承子类中，子类方法应该满足：１）前提条件不强于基类．２）后续条件不弱于基类．换句话说，通过基类的接口调用一个对象时，用户只知道基类前提条件以及后续条件。因此继承类不得要求用户提供比基类方法要求的更强的前提条件，亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。同样，继承类必须顺从基类的所有后续条件，亦即，继承类方法的行为和输出不得违反由基类建立起来的任何约束，不能让用户对继承类方法的输出感到困惑。这样，我们就有了基于合同的LSP，基于合同的LSP是LSP的一种强化。在很多情况下，在设计初期我们类之间的关系不是很明确，LSP则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!