OO设计原则 -- Liskov Substitution Principle: OO设计的LSP里氏
概要?Functions that use pointers or references to base classesmust 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设计原则的类的扩展不会给已有的系统引入新的错误。 类的继承原则：Robert C. Martin氏在介绍Liskov Substitution Principle (LSP)的原文里，举了Rectangle和Square的例子。 这里沿用这个例子，但用Java语言对其加以重写，并忽略了某些细节只列出下面的精要 部分来说明 里氏替换原则 对类的继承上的约束。 //代码：
class Rectangle {
double width;
doubleheight;
public double getHeight() {
returnheight;
}
public void setHeight(doubleheight) {
this.height = height;
}
public double getWidth() {
returnwidth;
}
public void setWidth(doublewidth) {
this.width = width;
}
}
class Square extends Rectangle {
public void setHeight(doubleheight) {
super.setHeight(height);
super.setWidth(height);
}
public void setWidth(doublewidth) {
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 = newSquare();
g(square);
时会抛出一个RuntimeException异常。这显然违反了LSP原则。 动作正确性保证：因为LSP对子类的约束，所以为已存在的类做扩展构造一个新的子类时， 根据LSP的定义，不会给已有的系统引入新的错误。 Design by Contract 根据Bertrand Meyer氏提出的Design by Contract（DBC：基于合同的设计）概念的描述， 对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等， 只有前提条件得到满足时，这个方法才能被调用；同时后续条件用来说明这个方法完成时的状态， 如果一个方法的执行会导致这个方法的后续条件不成立，那么 这个方法也不应该正常返回。 现在把前提条件以及后续条件应用到继承子类中，子类方法应该满足： １）前提条件不强于基类． ２）后续条件不弱于基类． 换 句话说，通过基类的接口调用一个对象时，用户只知道基类前提条件以及后续条件。 因此继承类不得要求用户提供比基类方法要求的更强的前提条件， 亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。 同样，继承类必须顺从基类的所有后续条件，亦即， 继承类方法的行为和输出不得违反由基类建立起来的任 何约束，不能让用户对继承类方法的输出感到困惑。 这样，我们就有了基于合同的LSP，基于合同的LSP是LSP的一种强化。 LSP则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。 总结
|