《设计模式》六大原则之一：里氏替换原则

《设计模式》六大原则：里氏替换原则

1 什么是里氏代换原则

里氏代换原则是由麻省理工学院（MIT）计算机科学实验室的Liskov女士，在1987年的OOPSLA大会上发表的一篇文章《Data Abstraction and Hierarchy》里面提出来的，主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中的蕴涵的原理。2002年，我们前面单一职责原则中提到的软件工程大师Robert C. Martin，出版了一本《Agile Software Development Principles Patterns and Practices》，在文中他把里氏代换原则最终简化为一句话：“Subtypes must be substitutable for their base types”。也就是，子类必须能够替换成它们的基类。

我们把里氏代换原则解释得更完整一些：在一个软件系统中，子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。

第一个实例：正方形不是长方形（违反里氏替换原则）

“正方形不是长方形”是一个理解里氏代换原则的最经典的例子。在数学领域里，正方形毫无疑问是长方形，它是一个长宽相等的长方形。所以，我们开发的一个与几何图形相关的软件系统中，让正方形继承自长方形是顺利成章的事情。

现在，我们截取该系统的一个代码片段进行分析：

长方形类Rectangle:

class Rectangle {  double length;  double width;  public double getLength() { return length; }   public void setLength(double height) { this.length = length; }     public double getWidth() { return width; }  public void setWidth(double width) { this.width = width; } }

正方形类Square:

class Square extends Rectangle {  public void setWidth(double width) {    super.setLength(width);    super.setWidth(width);    }  public void setLength(double length) {     super.setLength(length);    super.setWidth(length);     } }

由于正方形的度和宽度必须相等，所以在方法setLength和setWidth中，对长度和宽度赋值相同。

类TestRectangle是我们的软件系统中的一个组件，它有一个resize方法要用到基类Rectangle，resize方法的功能是模拟长方形宽度逐步增长的效果:

测试类TestRectangle：

class TestRectangle {  public void resize(Rectangle objRect) {    while(objRect.getWidth() <= objRect.getLength()  ) {        objRect.setWidth(  objRect.getWidth () + 1 );    }  }}

我们运行一下这段代码就会发现：

• 假如我们把一个普通长方形作为参数传入resize方法，就会看到长方形宽度逐渐增长的效果，当宽度大于长度,代码就会停止，这种行为的结果符合我们的预期；
• 假如我们再把一个正方形作为参数传入resize方法后，就会看到正方形的宽度和长度都在不断增长，代码会一直运行下去，直至系统产生溢出错误。所以，普通的长方形是适合这段代码的，正方形不适合。

我们得出结论：在resize方法中，Rectangle类型的参数是不能被Square类型的参数所代替，如果进行了替换就得不到预期结果。因此，Square类和Rectangle类之间的继承关系违反了里氏代换原则，它们之间的继承关系不成立，正方形不是长方形。

总结

里氏代换原则：在一个软件系统中，子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。

那么如何才能做到遵守里氏代换原则呢？？？
所有派生类的行为功能必须和使用者对其基类的期望保持一致，如果派生类达不到这一点，那么必然违反里氏替换原则。在实际的开发过程中，不正确的派生关系是非常有害的。伴随着软件开发规模的扩大，参与的开发人员也越来越多，每个人都在使用别人提供的组件，也会为别人提供组件。最终，所有人的开发的组件经过层层包装和不断组合，被集成为一个完整的系统。每个开发人员在使用别人的组件时，只需知道组件的对外裸露的接口，那就是它全部行为的集合，至于内部到底是怎么实现的，无法知道，也无须知道。所以，对于使用者而言，它只能通过接口实现自己的预期，如果组件接口提供的行为与使用者的预期不符，错误便产生了。里氏代换原则就是在设计时避免出现派生类与基类不一致的行为。

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能,如果改变了父类原有的功能，则将会导致派生类的行为功能和使用者对其基类的期望保持不一致带来错误。它包含以下4层含义：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类中可以增加自己特有的方法。
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

关于继承这里还说几点

• 继承包含这样一层含义：父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。
• 继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。

问题：如何正确地运用里氏代换原则

里氏代换原则目的就是要保证继承关系的正确性。我们在实际的项目中，是不是对于每一个继承关系都得费这么大劲去斟酌？不需要，大多数情况下按照“Is-A”去设计继承关系是没有问题的，只有极少的情况下，需要你仔细处理一下。

参考资料：http://blog.csdn.net/Bitou_Von/article/details/4210654