面向对象7大设计原则
目录
第1章 单一职责原则(SRP)
1.1 描述说明
1.2 如何使用单一职责原则
第2章 开放-封闭原则(OCP)
2.1 描述说明
2.2 如何使用开闭原则
2.3 开闭原则的实现方法
第3章 里氏替换原则（LSP）
3.1 描述说明
3.2 如何使用里氏替换原则
3.3 里氏替换原则的实现方法
第4章 依赖倒置原则（DIP）
4.1 描述说明
4.2 如何使用依赖倒置原则
第5章 接口隔离原则(ISP)
5.1 描述说明
5.2 如何使用接口隔离原则
第6章 合成/聚合复用原则（CRP/CARP）
6.1 描述说明
6.2 合成复用原则的实现方法
第7章 迪米特法则
7.1 描述说明
7.2 迪米特法则的实现方法
第1章 单一职责原则(SRP)
1.1 描述说明
- 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
- 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。
SRP是所有原则中最简单的之一，也是最难正确运用的之一。我们会自然的把职责结合到一起。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。事实上，我们要讨论的其余原则都会以这样那样的方式回到这个问题上。
1.2 如何使用单一职责原则
【例1】大学学生工作管理程序。
分析：大学学生工作主要包括学生生活辅导和学生学业指导两个方面的工作，其中生活辅导主要包括班委建设、出勤统计、心理辅导、费用催缴、班级管理等工作，学业指导主要包括专业引导、学习辅导、科研指导、学习总结等工作。如果将这些工作交给一位老师负责显然不合理，正确的做法是生活辅导由辅导员负责，学业指导由学业导师负责，其类图如图 1 所示。
图1 大学学生工作管理程序的类图
注意：单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。
第2章 开放-封闭原则(OCP)
2.1 描述说明
软件实体（类、模块、函数等等）应该是可以扩展的，但是不可修改的。
OCP背后的主要机制是抽象和多态。在静态类语言中，比如c++和java，支持抽象和多态的关键机制之一是继承。正是使用了继承，我们才可以创建实现其基类中抽象方法的派生类。
2.2 如何使用开闭原则
1、用抽象来隔离变化
用抽象来隔离变化，在我们认为可能发生变化的地方放置吊钩(hook)。对频繁变化的那部分做出抽象，隔离不同业务的具体的实现。
2、元数据（metadata）控制模块行为
例如，可以在数据库中配置什么业务对应什么处理类，根据业务找到处理类名再动态创建处理类进行处理：
| BUSI_TYPE | RES_KIND_ID | CLASS_NAME |
| LDSTORE | rsclM | CRsclMLdstoreLogic |
3、制定项目章程
2.3 开闭原则的实现方法
可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。
【例1】Windows 的桌面主题设计。
分析：Windows 的主题是桌面背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的桌面主题，也可以从网上下载新的主题。这些主题有共同的特点，可以为其定义一个抽象类（Abstract Subject），而每个具体的主题（Specific Subject）是其子类。用户窗体可以根据需要选择或者增加新的主题，而不需要修改原代码，所以它是满足开闭原则的，其类图如图 1 所示。
图1 Windows的桌面主题类图
第3章 里氏替换原则（LSP）
3.1 描述说明
- 里氏替换原则是实现开闭原则的重要方式之一。
- 它克服了继承中重写父类造成的可复用性变差的缺点。
- 它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。
3.2 如何使用里氏替换原则
3.3 里氏替换原则的实现方法
里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。
如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。
关于里氏替换原则的例子，最有名的是“正方形不是长方形”。当然，生活中也有很多类似的例子，例如，企鹅、鸵鸟和几维鸟从生物学的角度来划分，它们属于鸟类；但从类的继承关系来看，由于它们不能继承“鸟”会飞的功能，所以它们不能定义成“鸟”的子类。同样，由于“气球鱼”不会游泳，所以不能定义成“鱼”的子类；“玩具炮”炸不了敌人，所以不能定义成“炮”的子类等。
下面以“几维鸟不是鸟”为例来说明里氏替换原则。
【例2】里氏替换原则在“几维鸟不是鸟”实例中的应用。
分析：鸟一般都会飞行，如燕子的飞行速度大概是每小时 120 千米。但是新西兰的几维鸟由于翅膀退化无法飞行。假如要设计一个实例，计算这两种鸟飞行 300 千米要花费的时间。显然，拿燕子来测试这段代码，结果正确，能计算出所需要的时间；但拿几维鸟来测试，结果会发生“除零异常”或是“无穷大”，明显不符合预期，其类图如图 1 所示。
图1 “几维鸟不是鸟”实例的类图
第4章 依赖倒置原则（DIP）
4.1 描述说明
依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程。
依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。
由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。
使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。
依赖倒置原则（DependenceInversionPrinciple,DIP），原始定义包含三层含义：
- 依赖倒置原则可以降低类间的耦合性。
- 依赖倒置原则可以提高系统的稳定性。
- 依赖倒置原则可以减少并行开发引起的风险。
- 依赖倒置原则可以提高代码的可读性和可维护性。
4.2 如何使用依赖倒置原则
下面以“顾客购物程序”为例来说明依赖倒置原则的应用。
【例1】依赖倒置原则在“顾客购物程序”中的应用。
分析：本程序反映了 “顾客类”与“商店类”的关系。商店类中有 sell() 方法，顾客类通过该方法购物以下代码定义了顾客类通过韶关网店 ShaoguanShop 购物：
- class Customer
- {
- public void shopping(ShaoguanShop shop)
- {
- //购物
- System.out.println（shop.sell());
- }
- }
- class Customer
- {
- public void shopping(WuyuanShop shop)
- {
- //购物
- System.out.println(shop.sell());
- }
- }
- class Customer
- {
- public void shopping(Shop shop)
- {
- //购物
- System.out.println(shop.sell());
- }
- }
这样，不管顾客类 Customer 访问什么商店，或者增加新的商店，都不需要修改原有代码了，其类图如图 1 所示。
图1 顾客购物程序的类图
程序代码如下：
package principle;
public class DIPtest
{
public static void main(String[] args)
{
Customer wang=new Customer();
System.out.println("顾客购买以下商品：");
wang.shopping(new ShaoguanShop());
wang.shopping(new WuyuanShop());
}
}
//商店
interface Shop
{
public String sell(); //卖
}
//韶关网店
class ShaoguanShop implements Shop
{
public String sell()
{
return "韶关土特产：香菇、木耳……";
}
}
//婺源网店
class WuyuanShop implements Shop
{
public String sell()
{
return "婺源土特产：绿茶、酒糟鱼……";
}
}
//顾客
class Customer
{
public void shopping(Shop shop)
{
//购物
System.out.println(shop.sell());
}
}第5章 接口隔离原则(ISP)
5.1 描述说明
什么是隔离呢？它有两种定义，如下所示：
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
- 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
- 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。
- 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
- 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
- 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
- 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
- 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。
● 定制服务
5.2 如何使用接口隔离原则
【例1】学生成绩管理程序。
分析：学生成绩管理程序一般包含插入成绩、删除成绩、修改成绩、计算总分、计算均分、打印成绩信息、査询成绩信息等功能，如果将这些功能全部放到一个接口中显然不太合理，正确的做法是将它们分别放在输入模块、统计模块和打印模块等 3 个模块中，其类图如图 1 所示。
图1 学生成绩管理程序的类图
第6章 合成/聚合复用原则（CRP/CARP）
6.1 描述说明
合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，在一个新的对象中引入/注入现有的对象以达到功能复用和扩展的目的，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。
通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。
- 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
- 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
- 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。
采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。
- 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
- 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
- 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。
组合/聚合复用原则来源：
在面向对象的设计中，如果直接继承基类，会破坏封装，因为继承将基类的实现细节暴露给子类；如果基类的实现发生改变，则子类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性。于是就提出了组合/聚合复用原则，也就是在实际开发设计中，尽量使用合成/聚合，不要使用类继承。即在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新对象通过向这些对象的委派达到复用已有功能的目的。就是说要尽量的使用合成和聚合，而不是继承关系达到复用的目的。
组合/聚合复用原则定义：
合成/聚合复用原则经常又叫做合成复用原则。该原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分：新的对象通过向这些对象的委派达到复用已有功能的目的。
组合/聚合复用原则作用：
组合/聚合可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少；其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。 由于组合或聚合关系可以将已有的对象（也可称为成员对象）纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现细节对于新对象不可见，所以这种复用又称为“黑箱”复用，相对继承关系而言，其耦合度相对较低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作；合成复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。
组合/聚合复用原则示例：
合成（Composition，也有翻译成组合）和聚合（Aggregation），都是关联的特殊种类。聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；合成（组合）是一种强的“拥有”关系，体现了严格的部分与整体的关系，部分和整体的生命周期是一样的。聚合/组合UML示意图如图1所示：
在我们的日常开发中，经常遇到新的数据库或股市行情源替换问题，如下面的情况。产品初始开发采用A公司的行情源，与行情源操作有关的类如CustomerData类等都需要连接行情源，连接行情源的方法getConnection()封装在DataUtil类中，由于需要重用DataUtil类的getConnection()方法，设计人员将CustomerData作为DataUtil类的子类，初始设计方案结构如图2所示：
随着产品的正式上线，需要更加稳定快速的行情源，于是决定使用B公司行情源，但是B公司行情源数据解析模式和A公司不一样。因此需要增加一个新的DataUtilB类来连接B行情源，由于在初始设计方案中CustomerData和DataUtil之间是继承关系，因此在更换行情连接方式时需要修改CustomerData类的源代码，将CustomerData作为DataUtilB的子类，这将违反开闭原则。当然也可以修改DataUtil类的源代码，同样会违反开闭原则。
现使用合成复用原则对其进行重构。重构后的方案如图3所示：
重构后的CustomerData和DataUtil之间的关系由继承关系变为关联关系，采用依赖注入的方式将DataUtil对象注入到CustomerData中，可以使用构造注入，也可以使用Setter注入。如果需要对DataUtil的功能进行扩展，可以通过其子类来实现，如通过子类DataUtilB来连接B行情源。由于CustomerData针对DataUtil编程，根据里氏代换原则，DataUtil子类的对象可以覆盖DataUtil对象，只需在CustomerData中注入子类对象即可使用子类所扩展的方法。例如在CustomerData中注入DataUtilB对象，即可实现接入B行情源，原有代码不需要修改，且还可以很方便地增加新的行情接入。
合成/聚合复用优缺点和继承复用优缺点总结：
合成/聚合复用：
(1).优点：
新对象存取成分对象的唯一方法是通过成分对象的接口； 这种复用是黑箱复用，因为成分对象的内部细节是新对象所看不见的；这种复用支持包装；这种复用所需的依赖较少； 每一个新的类可以将焦点集中在一个任务上； 这种复用可以在运行时动态进行，新对象可以使用合成/聚合关系将新的责任委派到合适的对象。
(2).缺点：
通过这种方式复用建造的系统会有较多的对象需要管理。
继承复用:
(1).优点：
新的实现较为容易，因为基类的大部分功能可以通过继承关系自动进入派生类；修改或扩展继承而来的实现较为容易。
(2).缺点：
继承复用破坏包装，因为继承将基类的实现细节暴露给派生类，这种复用也称为白箱复用； 如果基类的实现发生改变，那么派生类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，不够灵活。
组合/聚合复用原则使用总结：
合成和聚合均是关联的特殊情况。聚合用来表示“拥有”关系或者整体与部分的关系；而合成则用来表示一种强得多的“拥有”关系。在一个合成关系里面，部分和整体的生命周期是一样的。一个合成的新的对象完全拥有对其组成部分的支配权，包括它们的创建和销毁等。使用程序语言的术语来说，组合而成的新对象对组成部分的内存分配、内存释放有绝对的责任。要正确的选择合成/复用和继承，必须透彻地理解里氏替换原则和Coad法则。（Coad法则由Peter Coad提出，总结了一些什么时候使用继承作为复用工具的条件。Coad法则：只有当以下Coad条件全部被满足时，才应当使用继承关系）
(1).子类是基类的一个特殊种类，而不是基类的一个角色。区分“Has-A”和“Is-A”。只有“Is-A”关系才符合继承关系，“Has-A”关系应当用聚合来描述。
(2).永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来是否会变成另外一个子类的话，就不要使用继承。
(3).子类具有扩展基类的责任，而不是具有置换掉（override）或注销掉（Nullify）基类的责任。如果一个子类需要大量的置换掉基类的行为，那么这个类就不应该是这个基类的子类。
(4).只有在分类学角度上有意义时，才可以使用继承。不要从工具类继承。
6.2 合成复用原则的实现方法
合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。
下面以汽车分类管理程序为例来介绍合成复用原则的应用。
【例1】汽车分类管理程序。
分析：汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。图 1 所示是用继淨：关系实现的汽车分类的类图。
图1 用继承关系实现的汽车分类的类图
从图 1 可以看出用继承关系实现会产生很多子类，而且增加新的“动力源”或者增加新的“颜色”都要修改源代码，这违背了开闭原则，显然不可取。但如果改用组合关系实现就能很好地解决以上问题，其类图如图 2 所示。
图2 用组合关系实现的汽车分类的类图
第7章 迪米特法则
7.1 描述说明
迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。
- 降低了类之间的耦合度，提高了模块的相对独立性。
- 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。
但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。
7.2 迪米特法则的实现方法
从迪米特法则的定义和特点可知，它强调以下两点：- 从依赖者的角度来说，只依赖应该依赖的对象。
- 从被依赖者的角度说，只暴露应该暴露的方法。
- 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
- 在类的结构设计上，尽量降低类成员的访问权限。
- 在类的设计上，优先考虑将一个类设置成不变类。
- 在对其他类的引用上，将引用其他对象的次数降到最低。
- 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
- 谨慎使用序列化（Serializable）功能。
分析：明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与粉丝的见面会，与媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则，其类图如图 1 所示。
图1 明星与经纪人的关系图
package principle;
public class LoDtest
{
public static void main(String[] args)
{
Agent agent=new Agent();
agent.setStar(new Star("林心如"));
agent.setFans(new Fans("粉丝韩丞"));
agent.setCompany(new Company("中国传媒有限公司"));
agent.meeting();
agent.business();
}
}
//经纪人
class Agent
{
private Star myStar;
private Fans myFans;
private Company myCompany;
public void setStar(Star myStar)
{
this.myStar=myStar;
}
public void setFans(Fans myFans)
{
this.myFans=myFans;
}
public void setCompany(Company myCompany)
{
this.myCompany=myCompany;
}
public void meeting()
{
System.out.println(myFans.getName()+"与明星"+myStar.getName()+"见面了。");
}
public void business()
{
System.out.println(myCompany.getName()+"与明星"+myStar.getName()+"洽淡业务。");
}
}
//明星
class Star
{
private String name;
Star(String name)
{
this.name=name;
}
public String getName()
{
return name;
}
}
//粉丝
class Fans
{
private String name;
Fans(String name)
{
this.name=name;
}
public String getName()
{
return name;
}
}
//媒体公司
class Company
{
private String name;
Company(String name)
{
this.name=name;
}
public String getName()
{
return name;
}
}参考资料：
《敏捷软件开发：原则、模式与实践》
《设计模式之禅（第2版）》
《Java设计模式：23种设计模式全面解析（超级详细）》：Java设计模式：23种设计模式全面解析（超级详细）