OO设计原则 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定义。

view plaincopy to clipboardprint?

01.if (obj typeof Class1) {

02. do something

03.} else if (obj typeof Class2) {

04. do something else

05.}

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语言对其加以重写，并忽略了某些细节只列出下面的精要

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

view plaincopy to clipboardprint?

01.//代码：

02.

03.class Rectangle {

04. double width;

05. doubleheight;

06.

07.

08. public double getHeight() {

09. returnheight;

10. }

11. public void setHeight(doubleheight) {

12. this.height = height;

13. }

14. public double getWidth() {

15. returnwidth;

16. }

17. public void setWidth(doublewidth) {

18. this.width = width;

19. }

20.}

21.

22.class Square extends Rectangle {

23. public void setHeight(doubleheight) {

24. super.setHeight(height);

25. super.setWidth(height);

26. }

27.

28. public void setWidth(doublewidth) {

29. super.setHeight(width);

30. super.setWidth(width);

31. }

32.}

//代码：

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继承。

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

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

view plaincopy to clipboardprint?

01.void g(Rectangle r) {

02. r.setWidth(5);

03. r.setHeight(4);

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

05. throw new RuntimeException();

06. }

07.}

void g(Rectangle r) {

r.setWidth(5);

r.setHeight(4);

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

throw new RuntimeException();

}

}

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

view plaincopy to clipboardprint?

01.Rectangle square = newSquare();

02.g(square);

Rectangle square = newSquare();

g(square);

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

动作正确性保证：

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

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

Design by Contract

根据Bertrand Meyer氏提出的Design by Contract（DBC：基于合同的设计）概念的描述，

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

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

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

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

１）前提条件不强于基类．

２）后续条件不弱于基类．

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

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

亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。

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

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

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

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

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

总结

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

Subtypes must besubstitutable for their base types.

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

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

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

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

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

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

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

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