软件架构设计的七大原则(下)

里氏替换原则
里氏替换原则（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支持的逻辑：

具体选择交给应用层，来看一下类图：

设计原则总结

学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。