架构师之路——里氏替换原则LSP

定义：

　　如果对每一个对类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。

内容：

　　里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：

1.子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

2.子类中可以增加自己特有的方法。

3.当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。

4.当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

经典例子：

　　1.长方形与正方形类，长方形类是父类，正方形类是子类从长方形派生出来。长方形是长宽不相等，正方形是长宽都相等的。因此执行ReSize时，便于溢出异常。

　　2.鸵鸟不是鸟，鸟类是基类，鸵鸟类从鸟类派生出来。他们拥有飞的方法，但鸵鸟不会飞，因此飞的速度为0。当计算飞越黄河时，需要的时间，鸵鸟类便会异常，返回了里氏替换原则。

实际项目开发如何做？

　　违背里氏代换原则的，其结果就是可维护性和可扩展性会变差。有人说：我这么用，效果好像不错，干嘛讲究那么多呢，实现需求是第一位的。另外，这种写法看起来很很直观的，有利于维护。其实，每个人所处的环境不同，对具体问题的理解不同，难免局限在自己的领域内思考问题。对于这个说法，我觉得应该这么解释：作为一个设计原则，是人们经过很多的项目实践，最终提炼出来的指导性的内容。如果对于你的项目来讲，显著增加了工作量和复杂度，那我觉得适度的违反并不为过。做任何事情都是个度的问题，过犹不及都不好。在大中型的项目中，是一定要讲究软件工程的思想，讲究规范和流程的，否则人员协作和后期维护将会是非常困难的。对于小型的项目可能相应的要简化很多，可能取决于时间、资源、商业等各种因素，但是多从软件工程的角度去思考问题，对于系统的健壮性、可维护性等性能指标的提高是非常有益的。像生命周期只有一个月的系统，你还去考虑一大堆原则，除非脑袋被驴踢了。
    实现开闭原则的关键步骤是抽象化，基类与子类之间的继承关系就是一种抽象化的体现。因此，里氏代换原则是实现抽象化的一种规范。违反里氏代换原则意味着违反了开闭原则，反之未必。里氏代换原则是使代码符合开闭原则的一个重要保证。