软件架构设计的七大原则(下)
里氏替换原则
里氏替换原则(Liskov Substitution Principle,LSP)是指如果对每一个类型为 T1 的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都替换成o2时,程序P的行为没有发生变化,那么类型T2是类型T1的子类型。
定义看上去还是比较抽象,我们重新理解一下,可以理解为一个软件实体如果适用一个父类的话,那一定是适用于其子类,所有引用父类的地方必须能透明地使用其子类的对象,子类对象能够替换父类对象,而程序逻辑不变。根据这个理解,我们总结一下:
引申含义:子类可以扩展父类的功能,但不能改变父类原有的功能。
1、子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
2、子类中可以增加自己特有的方法。
3、当子类的方法重载父类的方法时,方法的前置条件(即方法的输入/入参)要比父类方法的输入参数更宽松。
4、当子类的方法实现父类的方法时(重写/重载或实现抽象方法),方法的后置条件(即方法的输出/返回值)要比父类更严格或相等。
在前面讲开闭原则的时候埋下了一个伏笔,我们记得在获取折后时重写覆盖了父类的getPrice()方法,增加了一个获取源码的方法getOriginPrice(),显然就违背了里氏替换原则。我们修改一下代码,不应该覆盖getPrice()方法,增加getDiscountPrice()方法:
使用里氏替换原则有以下优点:
1、约束继承泛滥,开闭原则的一种体现。
2、加强程序的健壮性,同时变更时也可以做到非常好的兼容性,提高程序的维护性、扩展性。降低需求变更时引入的风险。
现在来描述一个经典的业务场景,用正方形、矩形和四边形的关系说明里氏替换原则,我们都知道正方形是一个特殊的长方形,那么就可以创建一个长方形父类Rectangle类:
创建正方形Square类继承长方形:
在测试类中创建resize()方法,根据逻辑长方形的宽应该大于等于高,我们让高一直自增,直到高等于宽变成正方形
测试代码
运行结果:
发现高比宽还大了,在长方形中是一种非常正常的情况。现在我们再来看下面的代码,把长方形Rectangle替换成它的子类正方形Square,修改测试代码:
这时候我们运行的时候就出现了死循环,违背了里氏替换原则,将父类替换为子类后,程序运行结果没有达到预期。因此,我们的代码设计是存在一定风险的。里氏替换原则只存在父类与子类之间,约束继承泛滥。我们再来创建一个基于长方形与正方形共同的抽象四边形Quadrangle接口:
修改长方形Rectangle类:
修改正方形类Square类:
此时,如果我们把resize()方法的参数换成四边形Quadrangle类,方法内部就会报错。因为正方形Square已经没有了setWidth()和setHeight()方法了。因此,为了约束继承泛滥,resize()的方法参数只能用Rectangle长方形。当然,我们在后面的设计模式课程中还会继续深入讲解。
合成复用原则
合成复用原则(Composite/Aggregate Reuse Principle,CARP)是指尽量使用对象组合(has-a)/聚合(contanis-a),而不是继承关系达到软件复用的目的。可以使系统更加灵活,降低类与类之间的耦合度,一个类的变化对其他类造成的影响相对较少。
继承我们叫做白箱复用,相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱复用,对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计,其实也都需要遵循OOP模型。还是以数据库操作为例,先来创建DBConnection类:
创建ProductDao类:
这就是一种非常典型的合成复用原则应用场景。但是,目前的设计来说,DBConnection还不是一种抽象,不便于系统扩展。目前的系统支持MySQL数据库连接,假设业务发生变化,数据库操作层要支持Oracle数据库。当然,我们可以在DBConnection中增加对Oracle数据库支持的方法。但是违背了开闭原则。其实,我们可以不必修改Dao的代码,将DBConnection修改为abstract,来看代码:
然后,将MySQL的逻辑抽离:
再创建Oracle支持的逻辑:
具体选择交给应用层,来看一下类图:
设计原则总结
学习设计原则,学习设计模式的基础。在实际开发过程中,并不是一定要求所有代码都遵循设计原则,我们要考虑人力、时间、成本、质量,不是刻意追求完美,要在适当的场景遵循设计原则,体现的是一种平衡取舍,帮助我们设计出更加优雅的代码结构。