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

时间:2023-03-09 15:24:11
架构师之路——里氏替换原则LSP

定义:

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

内容:

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

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

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

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

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

经典例子:

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

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

实际项目开发如何做?

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