23种设计模式-个人笔记(一)
目录
一、认识设计模式
1、软件设计模式的概念与意义
1.1、软件设计模式的概念
1.2、学习设计模式的意义
2、设计模式的目的
3、什么是设计模式的原则
4、掌握设计模式的层次
5、软件设计模式的基本要素
6、GoF 的 23 种设计模式的分类和功能
6.1、根据目的来分
6.2、根据作用范围来分
6.3、GoF的23种设计模式的功能
二、设计模式的七大原则
1、单一职责原则
1.1、单一职责原则的定义
1.2、单一职责原则的优点
1.3、单一职责原则的实现方法
1.4、什么是单一职责原则
1.5、应用实例
1.6、注意事项
2、接口隔离原则
2.1、接口隔离原则的定义
2.2、接口隔离原则的优点
2.3、接口隔离原则的实现方法
2.4、应用实例
3、依赖倒置原则
3.1、依赖倒置原则的定义
3.2、依赖、倒置原则的作用
3.3、依赖倒置原则的实现方法
3.4、应用实例
3.5、依赖传递的三种方式
3.6、注意事项
4、里氏替换原则
4.1、里氏替换原则的定义
4.2、里氏替换原则的作用
4.3、里氏替换原则的实现方法
4.4、应用实例
5、开闭原则
5.1、开闭原则的作用
5.2、开闭原则的实现方法
5.3、应用实例
6、迪米特法则
6.1、迪米特法则的定义
6.2、迪米特法则的优点
6.3、迪米特法则的实现方法
6.4、应用实例
6.5、注意事项
7、合成复用原则
7.1、合成复用原则的定义
7.2、合成复用原则的重要性
7.3、合成复用原则的实现方法
7.4、设计原则的核心思想
三、依赖、泛化、实现、关联、聚合、组合
1、类之间的关系
2、类图的六大关系
2.1、依赖
2.2、泛化
2.3、实现
2.4、关联
2.5、聚合
2.6、组合
一、认识设计模式
1、软件设计模式的概念与意义
有关软件设计模式的定义很多，有些从模式的特点来说明，有些从模式的作用来说明。本教程给出的定义是大多数学者公认的，从以下两个方面来说明。
1.1、软件设计模式的概念
软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
1.2、学习设计模式的意义
设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。正确使用设计模式具有以下优点。
- 可以提高程序员的思维能力、编程能力和设计能力。
- 使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
- 使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。
当然，软件设计模式只是一个引导。在具体的软件幵发中，必须根据设计的应用系统的特点和要求来恰当选择。对于简单的程序开发，可能写一个简单的算法要比引入某种设计模式更加容易。但对大项目的开发或者框架设计，用设计模式来组织代码显然更好。
2、设计模式的目的
编写软件的过程中，程序员面临着来自耦合性、内聚性以及可维护性、可扩展性、重用性、灵活性等多方面的挑战，设计模式是为了让程序拥有更好的：
- 代码可重用性。相同功能的代码，不用多次编写；
- 可读性。便于其他程序员的阅读和理解；
- 可扩展性。当需要增加新功能时，非常方便；
- 可靠性。当增加新的功能后，对原来的功能没有影响；
- 使程序呈现高内聚、低耦合的特点。
3、什么是设计模式的原则
设计模式原则，其实就是程序员在编程时，应当遵循的原则，也就是各种设计模式的基础，即设计模式为什么这样设计的依据。
设计模式的七大原则有：
- 单一职责原则
- 接口隔离原则
- 依赖倒置原则
- 里氏替换原则
- 开闭原则
- 迪米特法则
- 合成复用原则
4、掌握设计模式的层次
第1层：刚开始学编程不久，听说过什么是设计模式
第2层：有很长时间的编程经验，自己写了很多代码，其中用到了设计模式，但 是自己却不知道
第3层：学习过了设计模式，发现自己已经在使用了，并且发现了一些新的模式 挺好用的
第4层：阅读了很多别人写的源码和框架，在其中看到别人设计模式，并且能够 领会设计模式的精妙和带来的好处。
第5层：代码写着写着，自己都没有意识到使用了设计模式，并且熟练的写了出来
5、软件设计模式的基本要素
软件设计模式使人们可以更加简单方便地复用成功的设计和体系结构，它通常包含以下几个基本要素：模式名称、别名、动机、问题、解决方案、效果、结构、模式角色、合作关系、实现方法、适用性、已知应用、例程、模式扩展和相关模式等，其中最关键的元素包括以下 4 个主要部分。
1. 模式名称
每一个模式都有自己的名字，通常用一两个词来描述，可以根据模式的问题、特点、解决方案、功能和效果来命名。模式名称（PatternName）有助于我们理解和记忆该模式，也方便我们来讨论自己的设计。
2. 问题
问题（Problem）描述了该模式的应用环境，即何时使用该模式。它解释了设计问题和问题存在的前因后果，以及必须满足的一系列先决条件。
3. 解决方案
模式问题的解决方案（Solution）包括设计的组成成分、它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象的 组合）来解决这个问题。
4. 效果
描述了模式的应用效果以及使用该模式应该权衡的问题，即模式的优缺点。主要是对时间和空间的衡量，以及该模式对系统的灵活性、扩充性、可移植性的影响，也考虑其实现问题。显式地列出这些效果（Consequence）对理解和评价这些模式有很大的帮助。
6、GoF 的 23 种设计模式的分类和功能
设计模式有两种分类方法，即根据模式的目的来分和根据模式的作用的范围来分。
6.1、根据目的来分
根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。
- 创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式
- 结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，共七种：适配器模式、装饰者模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
- 行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
6.2、根据作用范围来分
根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。
- 类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。GoF中的工厂方法、（类）适配器、模板方法、解释器属于该模式。
- 对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。GoF 中除了以上 4 种，其他的都是对象模式。
表 1 介绍了这 23 种设计模式的分类。
| 范围\目的 | 创建型模式 | 结构型模式 | 行为型模式 |
|---|---|---|---|
| 类模式 | 工厂方法 | (类）适配器 | 模板方法、解释器 |
| 对象模式 | 单例 工厂方法 |
代理 (对象）适配器 桥接 装饰 外观 享元 组合 |
策略 命令 职责链 状态 观察者 中介者 迭代器 访问者 备忘录 |
6.3、GoF的23种设计模式的功能
前面说明了 GoF 的 23 种设计模式的分类，现在对各个模式的功能进行介绍。
- 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
- 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
- 工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
- 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
- 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
- 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
- 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
- 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
- 装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。
- 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
- 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
- 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
- 模板方法（TemplateMethod）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
- 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
- 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
- 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
- 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
- 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
- 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
- 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
- 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
- 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
- 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。
必须指出，这 23 种设计模式不是孤立存在的，很多模式之间存在一定的关联关系，在大的系统开发中常常同时使用多种设计模式，希望读者认真学好它们。
二、设计模式的七大原则
1、单一职责原则
1.1、单一职责原则的定义
单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。
该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
- 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
- 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。
1.2、单一职责原则的优点
单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。
- 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
- 提高类的可读性。复杂性降低，自然其可读性会提高。
- 提高系统的可维护性。可读性提高，那自然更容易维护了。
- 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。
1.3、单一职责原则的实现方法
单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。下面以大学学生工作管理程序为例介绍单一职责原则的应用。
1.4、什么是单一职责原则
对类来说，一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2，当职责1需求变更而改变类A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2。
【例1】大学学生工作管理程序。
分析：大学学生工作主要包括学生生活辅导和学生学业指导两个方面的工作，其中生活辅导主要包括班委建设、出勤统计、心理辅导、费用催缴、班级管理等工作，学业指导主要包括专业引导、学习辅导、科研指导、学习总结等工作。如果将这些工作交给一位老师负责显然不合理，正确的做 法是生活辅导由辅导员负责，学业指导由学业导师负责，其类图如图 1 所示。
图1 大学学生工作管理程序的类图
注意：单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。
1.5、应用实例
方案一：方案一的run方法中，违反了单一职责原则
public class SingleResponsebility1 {
public static void main(String[] args) {
Vehicle vehicle = new Vehicle();
vehicle.run("汽车");
vehicle.run("摩托");
vehicle.run("飞机");
}
}
class Vehicle {
public void run(String vehicle) {
System.out.println(vehicle+"在公路上跑");
}
}
解决的方案：根据交通工具运行方法不同，分解成不同类即可
方案二：方案二遵循单一职责原则，但是这样做的改动很大，即将类分解，同时修改客户端
public class SingleResponsibility2 {
public static void main(String[] args) {
Vehicle1 vehicle1 = new Vehicle1();
vehicle1.run("汽车");
Vehicle2 vehicle2 = new Vehicle2();
vehicle2.run("轮船");
Vehicle3 vehicle3 = new Vehicle3();
vehicle3.run("飞机");
}
}
class Vehicle1{
public void run(String vehicle){
System.out.println(vehicle+"在地上跑");
}
}
class Vehicle2{
public void run(String vehicle){
System.out.println(vehicle+"在水上跑");
}
}
class Vehicle3{
public void run(String vehicle){
System.out.println(vehicle+"在天上跑");
}
}
改进：直接修改Vehicle类，改动的代码会比较少
方案三：这种修改方法没有对原来的类做大的修改，只是增加方法。这里虽然没有在类这个级别上遵循单一职责原则，但是在方法级别上，仍然遵守这个原则
public class SingleResonsibility3 {
public static void main(String[] args) {
Vehicle4 vehicle4 = new Vehicle4();
vehicle4.run("汽车");
vehicle4.run2("轮船");
vehicle4.run3("飞机");
}
}
class Vehicle4{
public void run(String vehicle){
System.out.println(vehicle+"在地上跑");
}
public void run2(String vehicle){
System.out.println(vehicle+"在水上跑");
}
public void run3(String vehicle) {
System.out.println(vehicle + "在天上跑");
}
}
1.6、注意事项
- 降低类的复杂度，一个类只负责一项职责；
- 提高类的可读性、可维护性；
- 降低变更引起的风险；
- 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则：只有类中方法数量足够少，可以在方法级别保存单一职责原则。
2、接口隔离原则
2.1、接口隔离原则的定义
接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。
2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use）。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。
以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
- 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
- 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。
2.2、接口隔离原则的优点
接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。
- 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
- 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
- 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
- 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
- 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。
2.3、接口隔离原则的实现方法
在具体应用接口隔离原则时，应该根据以下几个规则来衡量。
- 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
- 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
- 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
下面以学生成绩管理程序为例介绍接口隔离原则的应用。
【例1】学生成绩管理程序。
分析：学生成绩管理程序一般包含插入成绩、删除成绩、修改成绩、计算总分、计算均分、打印成绩信息、査询成绩信息等功能，如果将这些功能全部放到一个接口中显然不太合理，正确的做法是将它们分别放在输入模块、统计模块和打印模块等 3 个模块中，其类图如图 1 所示。
图1 学生成绩管理程序的类图
程序代码如下：
public class ISPtest {
public static void main(String[] args) {
InputModule input = StuScoreList.getInputModule();
CountModule count = StuScoreList.getCountModule();
PrintModule print = StuScoreList.getPrintModule();
input.insert();
count.countTotalScore();
print.printStuInfo();
//print.delete();
}
}
//输入模块接口
interface InputModule {
void insert();
void delete();
void modify();
}
//统计模块接口
interface CountModule {
void countTotalScore();
void countAverage();
}
//打印模块接口
interface PrintModule {
void printStuInfo();
void queryStuInfo();
}
//实现类
class StuScoreList implements InputModule, CountModule, PrintModule {
private StuScoreList() {
}
public static InputModule getInputModule() {
return (InputModule) new StuScoreList();
}
public static CountModule getCountModule() {
return (CountModule) new StuScoreList();
}
public static PrintModule getPrintModule() {
return (PrintModule) new StuScoreList();
}
public void insert() {
System.out.println("输入模块的insert()方法被调用！");
}
public void delete() {
System.out.println("输入模块的delete()方法被调用！");
}
public void modify() {
System.out.println("输入模块的modify()方法被调用！");
}
public void countTotalScore() {
System.out.println("统计模块的countTotalScore()方法被调用！");
}
public void countAverage() {
System.out.println("统计模块的countAverage()方法被调用！");
}
public void printStuInfo() {
System.out.println("打印模块的printStuInfo()方法被调用！");
}
public void queryStuInfo() {
System.out.println("打印模块的queryStuInfo()方法被调用！");
}
}程序的运行结果如下：
输入模块的insert()方法被调用！
统计模块的countTotalScore()方法被调用！
打印模块的printStuInfo()方法被调用！2.4、应用实例
如图，类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D，如果接口Interface1对于类A和类C来说不是最小接口，那么类B和类D必须去实现他们不需要的方法。
public class Segregation1 {
}
//接口
interface Interface1 {
void operation1();
void operation2();
void operation3();
void operation4();
void operation5();
}
class B implements Interface1 {
@Override
public void operation1() {
System.out.println("B实现了operation1");
}
@Override
public void operation2() {
System.out.println("B实现了operation2");
}
@Override
public void operation3() {
System.out.println("B实现了operation3");
}
@Override
public void operation4() {
System.out.println("B实现了operation4");
}
@Override
public void operation5() {
System.out.println("B实现了operation5");
}
}
class D implements Interface1 {
@Override
public void operation1() {
System.out.println("D实现了operation1");
}
@Override
public void operation2() {
System.out.println("D实现了operation2");
}
@Override
public void operation3() {
System.out.println("D实现了operation3");
}
@Override
public void operation4() {
System.out.println("D实现了operation4");
}
@Override
public void operation5() {
System.out.println("D实现了operation5");
}
}
class A {
public void depend1(Interface1 i) {
i.operation1();
}
public void depend2(Interface1 i) {
i.operation2();
}
public void depend3(Interface1 i) {
i.operation3();
}
}
class C {
public void depend1(Interface1 i) {
i.operation1();
}
public void depend4(Interface1 i) {
i.operation4();
}
public void depend5(Interface1 i) {
i.operation5();
}
}
按隔离原则应当这样处理：将接口Interface1拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
public class Segregation2 {
public static void main(String[] args) {
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());
C c = new C();
c.depend1(new D());
c.depend4(new D());
c.depend5(new D());
}
}
//接口
interface Interface1 {
void operation1();
}
interface Interface2 {
void operation2();
void operation3();
}
interface Interface3 {
void operation4();
void operation5();
}
class B implements Interface1, Interface2 {
@Override
public void operation1() {
System.out.println("B实现了operation1");
}
@Override
public void operation2() {
System.out.println("B实现了operation2");
}
@Override
public void operation3() {
System.out.println("B实现了operation3");
}
}
class D implements Interface1, Interface3 {
@Override
public void operation1() {
System.out.println("D实现了operation1");
}
@Override
public void operation4() {
System.out.println("D实现了operation4");
}
@Override
public void operation5() {
System.out.println("D实现了operation5");
}
}
class A {
public void depend1(Interface1 i) {
i.operation1();
}
public void depend2(Interface2 i) {
i.operation2();
}
public void depend3(Interface2 i) {
i.operation3();
}
}
class C {
public void depend1(Interface1 i) {
i.operation1();
}
public void depend4(Interface3 i) {
i.operation4();
}
public void depend5(Interface3 i) {
i.operation5();
}
}
3、依赖倒置原则
3.1、依赖倒置原则的定义
依赖倒置原则（Dependence Inversion Principle，DIP）是 Object Mentor 公司总裁罗伯特·马丁（Robert C.Martin）于 1996 年在 C++ Report 上发表的文章。
依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（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）。其核心思想是：要面向接口编程，不要面向实现编程。依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。
由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。
使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。
3.2、依赖、倒置原则的作用
依赖倒置原则的主要作用如下。
- 依赖倒置原则可以降低类间的耦合性。
- 依赖倒置原则可以提高系统的稳定性。
- 依赖倒置原则可以减少并行开发引起的风险。
- 依赖倒置原则可以提高代码的可读性和可维护性。
3.3、依赖倒置原则的实现方法
依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。
- 每个类尽量提供接口或抽象类，或者两者都具备。
- 变量的声明类型尽量是接口或者是抽象类。
- 任何类都不应该从具体类派生。
- 使用继承时尽量遵循里氏替换原则。
下面以“顾客购物程序”为例来说明依赖倒置原则的应用。
【例1】依赖倒置原则在“顾客购物程序”中的应用。
分析：本程序反映了 “顾客类”与“商店类”的关系。商店类中有 sell() 方法，顾客类通过该方法购物以下代码定义了顾客类通过韶关网店 ShaoguanShop 购物：
class Customer {
public void shopping(ShaoguanShop shop) {
//购物
System.out.println(shop.sell());
}
}但是，这种设计存在缺点，如果该顾客想从另外一家商店（如婺源网店 WuyuanShop）购物，就要将该顾客的代码修改如下：
class Customer {
public void shopping(WuyuanShop shop) {
//购物
System.out.println(shop.sell());
}
}顾客每更换一家商店，都要修改一次代码，这明显违背了开闭原则。存在以上缺点的原因是：顾客类设计时同具体的商店类绑定了，这违背了依赖倒置原则。解决方法是：定义“婺源网店”和“韶关网店”的共同接口 Shop，顾客类面向该接口编程，其代码修改如下：
class Customer {
public void shopping(Shop shop) {
//购物
System.out.println(shop.sell());
}
}这样，不管顾客类 Customer 访问什么商店，或者增加新的商店，都不需要修改原有代码了，其类图如图 1 所示。
图1 顾客购物程序的类图
程序代码如下：
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());
}
}程序的运行结果如下：
顾客购买以下商品：
韶关土特产：香菇、木耳……
婺源土特产：绿茶、酒糟鱼……3.4、应用实例
请编程完成persion接收消息的功能。
方案一：
public class DependecyInversion {
public static void main(String[] args) {
Persion persion = new Persion();
persion.receive(new Email());
}
}
class Email {
public String getInfo() {
return "电子邮件：Hello World!!!";
}
}
class Persion {
public void receive(Email e) {
System.out.println(e.getInfo());
}
}方案二：如果我们获取的对象是微信、短信等等，则新增类，同时Persion也要增加相应的接收方法
解决思路：引入一个抽象的接口IReceiver，表示接收者，这样Persion类与接口IReceiver发生依赖，因为Email、WeChat等等属于接收的范围，它们各自实现IReceiver接口就可以，这样我们就符合依赖倒置原则
public class DependecyInversion2 {
public static void main(String[] args) {
Persion2 persion2 = new Persion2();
persion2.receive(new Email2());
persion2.receive(new WeChat());
}
}
interface IReceiver {
public String getInfo();
}
class Email2 implements IReceiver {
@Override
public String getInfo() {
return "电子邮件：Hello World!";
}
}
class WeChat implements IReceiver {
@Override
public String getInfo() {
return "微信消息：Hello weixin";
}
}
class Persion2 {
public void receive(IReceiver i) {
System.out.println(i.getInfo());
}
}
3.5、依赖传递的三种方式
接口传递、构造方法传递、setter方法传递。
第一种方式：接口传递
// 开关的接口
interface IOpenAndClose {
public void open(ITV tv);//抽象方法，接收接口
}
interface ITV {//ITV接口
public void play();
}
// 实现接口
class OpenAndClose implements IOpenAndClose {
@Override
public void open(ITV tv) {
tv.play();
}
}
class ChangHong implements ITV{
@Override
public void play() {
System.out.println("长虹电视, 打开");
}
}第二种方式：构造方法
interface IOpenAndClose {
public void open();//抽象方法
}
// ITV接口
interface ITV {
public void play();
}
class OpenAndClose implements IOpenAndClose {
public ITV tv;//成员
public OpenAndClose(ITV tv) {//构造方法
this.tv = tv;
}
@Override
public void open() {
this.tv.play();
}
}
class ChangHong implements ITV{
@Override
public void play() {
System.out.println("长虹电视, 打开");
}
}方式三：setter方法传递
interface IOpenAndClose {
public void open();//抽象方法
}
interface ITV {//ITV接口
public void play();
}
class OpenAndClose implements IOpenAndClose {
private ITV tv;
public void setTv(ITV tv) {
this.tv = tv;
}
@Override
public void open() {
this.tv.play();
}
}
class ChangHong implements ITV{
@Override
public void play() {
System.out.println("长虹电视, 打开");
}
}public class DependecyPass {
public static void main(String[] args) {
ChangHong changHong = new ChangHong();
// 第一种方式：接口传递
OpenAndClose openAndColse = new OpenAndClose();
openAndColse.open(changHong);
// 方式二：构造方法传递
OpenAndClose openAndClose = new OpenAndClose(changHong);
openAndClose.open();
//方式三：setter方法传递
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.setTv(changHong);
openAndClose.open();
}
}3.6、注意事项
- 底层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好。
- 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化。
- 继承时要遵循里氏替换原则。
4、里氏替换原则
4.1、里氏替换原则的定义
里氏替换原则（Liskov Substitution Principle，LSP）由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立（Inheritance should ensure that any property proved about supertype objects also holds for subtype objects）。
里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。
关于继承性的思考和说明
- 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
- 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。
- 所以，在编程中，如何正确的使用继承？使用里氏替换原则。
4.2、里氏替换原则的作用
里氏替换原则的主要作用如下。
- 里氏替换原则是实现开闭原则的重要方式之一。
- 它克服了继承中重写父类造成的可复用性变差的缺点。
- 它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。
- 加强程序的健壮性，同时变更时可以做到非常好的兼容性，提高程序的维护性、可扩展性，降低需求变更时引入的风险。
4.3、里氏替换原则的实现方法
里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
根据上述理解，对里氏替换原则的定义可以总结如下：
- 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
- 子类中可以增加自己特有的方法
- 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松
- 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等
通过重写父类的方法来完成新的功能写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。
如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。
关于里氏替换原则的例子，最有名的是“正方形不是长方形”。当然，生活中也有很多类似的例子，例如，企鹅、鸵鸟和几维鸟从生物学的角度来划分，它们属于鸟类；但从类的继承关系来看，由于它们不能继承“鸟”会飞的功能，所以它们不能定义成“鸟”的子类。同样，由于“气球鱼”不会游泳，所以不能定义成“鱼”的子类；“玩具炮”炸不了敌人，所以不能定义成“炮”的子类等。
下面以“几维鸟不是鸟”为例来说明里氏替换原则。
【例1】里氏替换原则在“几维鸟不是鸟”实例中的应用。
分析：鸟一般都会飞行，如燕子的飞行速度大概是每小时 120 千米。但是新西兰的几维鸟由于翅膀退化无法飞行。假如要设计一个实例，计算这两种鸟飞行 300 千米要花费的时间。显然，拿燕子来测试这段代码，结果正确，能计算出所需要的时间；但拿几维鸟来测试，结果会发生“除零异常”或是“无穷大”，明显不符合预期，其类图如图 1 所示。
图1 “几维鸟不是鸟”实例的类图
程序代码如下：
public class LSPtest {
public static void main(String[] args) {
Bird bird1 = new Swallow();
Bird bird2 = new BrownKiwi();
bird1.setSpeed(120);
bird2.setSpeed(120);
System.out.println("如果飞行300公里：");
try {
System.out.println("燕子将飞行" + bird1.getFlyTime(300) + "小时.");
System.out.println("几维鸟将飞行" + bird2.getFlyTime(300) + "小时。");
} catch (Exception err) {
System.out.println("发生错误了!");
}
}
}
//鸟类
class Bird {
double flySpeed;
public void setSpeed(double speed) {
flySpeed = speed;
}
public double getFlyTime(double distance) {
return (distance / flySpeed);
}
}
//燕子类
class Swallow extends Bird {
}
//几维鸟类
class BrownKiwi extends Bird {
public void setSpeed(double speed) {
flySpeed = 0;
}
}程序的运行结果如下：
如果飞行300公里：
燕子将飞行2.5小时.
几维鸟将飞行Infinity小时。 程序运行错误的原因是：几维鸟类重写了鸟类的 setSpeed(double speed) 方法，这违背了里氏替换原则。正确的做法是：取消几维鸟原来的继承关系，定义鸟和几维鸟的更一般的父类，如动物类，它们都有奔跑的能力。几维鸟的飞行速度虽然为 0，但奔跑速度不为 0，可以计算出其奔跑 300 千米所要花费的时间。其类图如图 2 所示。
图2 “几维鸟是动物”实例的类图
4.4、应用实例
一个程序引发的问题和思考。
public class Liskow1 {
public static void main(String[] args) {
A a = new A();
System.out.println("11-3=" + a.func1(11, 3));
B b = new B();
System.out.println("11-3=" + b.func1(11, 3));//这里本意是求出11-3
System.out.println("11+3+9=" + b.func2(11, 3));
}
}
class A {
// 重写了A类的方法，可能是无意识的
public int func1(int num1, int num2) {
return num1 - num2;
}
}
class B extends A {
public int func1(int a, int b) {
return a + b;
}
public int func2(int a, int b) {
return func1(a, b) + 9;
}
}
我们发现原来运行正常的相减功能发生了错误，原因就是类B无意中重写了父类的方法，造成原有功能出现错误。在实际编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差，特别是运行多态比较频繁的时候。
通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系替代。
public class Liskov {
public static void main(String[] args) {
A a = new A();
System.out.println("11-3=" + a.func1(11, 3));
B b = new B();
//因为B类不再继承A类，因此调用者，不会再认为func1是求减法的。
//调用完成的功能就会很明确
System.out.println("11+3=" + b.func1(11, 3));
System.out.println("11+3+9=" + b.func2(11, 3));
//使用组合仍然可以使用到A类相关方法
System.out.println("11-3=" + b.func3(11, 3));
}
}
class Base {
//把更加基础的方法和成员写到Base类
}
class A extends Base {
// 重写了A类的方法，可能是无意识的
public int func1(int num1, int num2) {
return num1 - num2;
}
}
class B extends Base {
//如果B需要使用A的方法，使用组合关系
private A a = new A();
public int func1(int a, int b) {
return a + b;
}
public int func2(int a, int b) {
return func1(a, b) + 9;
}
//如果我们仍然想使用A的方法
public int func3(int a, int b) {
return this.a.func1(a, b);
}
}
5、开闭原则
开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出：软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。
开闭原则是编程中最基础、最重要的设计原则。
一个软件实体如类、模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，用实现扩展细节。
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则。
这里的软件实体包括以下几个部分：
- 项目中划分出的模块
- 类与接口
- 方法
开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。
5.1、开闭原则的作用
开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。
1. 对软件测试的影响
软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。
2. 可以提高代码的可复用性
粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。
3. 可以提高软件的可维护性
遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。
5.2、开闭原则的实现方法
可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。
下面以 Windows 的桌面主题为例介绍开闭原则的应用。
【例1】Windows 的桌面主题设计。
分析：Windows 的主题是桌面背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的桌面主题，也可以从网上下载新的主题。这些主题有共同的特点，可以为其定义一个抽象类（Abstract Subject），而每个具体的主题（Specific Subject）是其子类。用户窗体可以根据需要选择或者增加新的主题，而不需要修改原代码，所以它是满足开闭原则的，其类图如图 1 所示。
图1 Windows的桌面主题类图
5.3、应用实例
看一段画图代码。
public class Ocp {
public static void main(String[] args) {
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
}
}
//这是一个用于绘图的类
class GraphicEditor {
//接收Shape时对象，然后根据type，来绘制不同的图形
public void drawShape(Shape s) {
if (s.m_type == 1) {
drawRectangle(s);
} else if (s.m_type == 2) {
drawCircle(s);
}
}
public void drawRectangle(Shape r) {
System.out.println("绘制矩形");
}
public void drawCircle(Shape r) {
System.out.println("绘制圆形");
}
}
//Shape类，基类
class Shape {
int m_type;
}
class Rectangle extends Shape {
Rectangle() {
super.m_type = 1;
}
}
class Circle extends Shape {
Circle() {
super.m_type = 2;
}
}这段代码的优点是比较好理解，简单易操作。
缺点是违反了设计模式的开闭原则，即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码。
比如我们这时要新增加一个图形种类：三角形，我们需要修改的地方较多。
改进方案：把Shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现即可，这样我们有新的图形种类时，只需要让新的图形类继承Shape，并实现draw方法即可，“使用方”的代码就不需要修改，满足了开闭原则。
public class Ocp {
public static void main(String[] args) {
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
}
}
//这是一个用于绘图的类
class GraphicEditor {
//接收Shape时对象，然后根据type，来绘制不同的图形
public void drawShape(Shape s) {
s.draw();
}
}
//Shape类，基类
abstract class Shape {
public abstract void draw();//抽象方法
}
class Rectangle extends Shape {
@Override
public void draw() {
System.out.println("绘制矩形");
}
}
class Circle extends Shape {
@Override
public void draw() {
System.out.println("绘制圆形");
}
}6、迪米特法则
6.1、迪米特法则的定义
迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。
迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。
6.2、迪米特法则的优点
迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。
- 降低了类之间的耦合度，提高了模块的相对独立性。
- 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。
但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。
6.3、迪米特法则的实现方法
从迪米特法则的定义和特点可知，它强调以下两点：
- 从依赖者的角度来说，只依赖应该依赖的对象。
- 从被依赖者的角度说，只暴露应该暴露的方法。
所以，在运用迪米特法则时要注意以下 6 点。
- 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
- 在类的结构设计上，尽量降低类成员的访问权限。
- 在类的设计上，优先考虑将一个类设置成不变类。
- 在对其他类的引用上，将引用其他对象的次数降到最低。
- 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
- 谨慎使用序列化（Serializable）功能。
【例1】明星与经纪人的关系实例。
分析：明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与粉丝的见面会，与媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则，其类图如图 1 所示。
图1 明星与经纪人的关系图
程序代码如下：
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;
}
}程序的运行结果如下：
粉丝韩丞与明星林心如见面了。
中国传媒有限公司与明星林心如洽淡业务。6.4、应用实例
编程实现以下功能：有一个学校，下属有各个学院和总部，现要求打印出学校总部员工ID和学院员工的id。
public class Demeter {
public static void main(String[] args) {
SchoolManager schoolManager = new SchoolManager();
schoolManager.printAllEmployee(new CollegeManager());
}
}
//学校总部员工
class Employee {
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//学院员工
class CollegeEmployee {
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//管理学院员工的类
class CollegeManager {
//返回学院的所有员工
public List getAllEmployee() {
List list = new ArrayList();
for (int i = 0; i < 10; i++) {//增加了10个员工
CollegeEmployee emp = new CollegeEmployee();
emp.setId("学院员工id=" + i);
list.add(emp);
}
return list;
}
}
/**
* 管理学校员工的类
* 分析：SchoolManager类的直接朋友有哪些？
* 直接朋友有“Employee”、“CollegeManager”
* 非直接朋友有“CollegeEmployee”
* 这就违背了迪米特法则
*/
class SchoolManager {
//返回学校总部的员工
public List getAllEmployee() {
List list = new ArrayList();
for (int i = 0; i < 5; i++) { //增加了5个员工
Employee emp = new Employee();
emp.setId("学校总部员工id= " + i);
list.add(emp);
}
return list;
}
//完成输出学校总部和学院员工信息的方法
void printAllEmployee(CollegeManager sub) {
//获取学院员工
//CollegeEmployee是以局部变量的形式出现在SchoolManager类中
//解决方案：将获取学院员工的方法封装到CollegeManager中
List list1 = sub.getAllEmployee();
System.out.println("------------学院员工------------");
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
//获取学校总部员工
List list2 = this.getAllEmployee();
System.out.println("------------学校总部员工------------");
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}
前面设计的问题在于SchoolManager中，CollegeEmployee类并不是SchoolManager类的直接朋友。
按照迪米特法则，应该避免出现非直接朋友关系的耦合。
对代码按照迪米特法则进行改进如下：
public class Demeter {
public static void main(String[] args) {
SchoolManager schoolManager = new SchoolManager();
schoolManager.printAllEmployee(new CollegeManager());
}
}
//学校总部员工
class Employee {
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//学院员工
class CollegeEmployee {
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//管理学院员工的类
class CollegeManager {
//返回学院的所有员工
public List getAllEmployee() {
List list = new ArrayList();
for (int i = 0; i < 10; i++) {//增加了10个员工
CollegeEmployee emp = new CollegeEmployee();
emp.setId("学院员工id=" + i);
list.add(emp);
}
return list;
}
//获取学院员工
public void printEmployee() {
List list1 = this.getAllEmployee();
System.out.println("------------学院员工------------");
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
}
}
/**
* 管理学校员工的类
* 分析：SchoolManager类的直接朋友有哪些？
* 直接朋友有“Employee”、“CollegeManager”
* 非直接朋友有“CollegeEmployee”
* 这就违背了迪米特法则
*/
class SchoolManager {
//返回学校总部的员工
public List getAllEmployee() {
List list = new ArrayList();
for (int i = 0; i < 5; i++) { //增加了5个员工
Employee emp = new Employee();
emp.setId("学校总部员工id= " + i);
list.add(emp);
}
return list;
}
//完成输出学校总部和学院员工信息的方法
void printAllEmployee(CollegeManager sub) {
//获取学院员工
sub.printEmployee();
//获取学校总部员工
List list2 = this.getAllEmployee();
System.out.println("------------学校总部员工------------");
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}
6.5、注意事项
迪米特法则的核心是降低类之间的耦合性。
但是注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间（对象间）耦合关系，并不是要求完全没有依赖关系。
7、合成复用原则
7.1、合成复用原则的定义
合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。
7.2、合成复用原则的重要性
通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。
- 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
- 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
- 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。
采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。
- 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
- 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
- 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。
7.3、合成复用原则的实现方法
合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。
下面以汽车分类管理程序为例来介绍合成复用原则的应用。
【例1】汽车分类管理程序。
分析：汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。图 1 所示是用继承关系实现的汽车分类的类图。
图1 用继承关系实现的汽车分类的类图
从图 1 可以看出用继承关系实现会产生很多子类，而且增加新的“动力源”或者增加新的“颜色”都要修改源代码，这违背了开闭原则，显然不可取。但如果改用组合关系实现就能很好地解决以上问题，其类图如图 2 所示。
图2 用组合关系实现的汽车分类的类图
7.4、设计原则的核心思想
- 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起；
- 针对接口编程，而不是针对实现编程；
- 为了交互对象之间的松耦合设计而努力。
三、依赖、泛化、实现、关联、聚合、组合
1、类之间的关系
在软件系统中，类不是孤立存在的，类与类之间存在各种关系。根据类与类之间的耦合度从弱到强排列，UML 中的类图有以下几种关系：依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。
类之间的关系有：依赖、泛化、实现、关联、聚合、组合。
2、类图的六大关系
2.1、依赖
依赖（Dependency）关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。
在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。图 4 所示是人与手机的关系图，人通过手机的语音传送方法打电话。
图4 依赖关系的实例
对应的类图：
public class PersonServiceBean {
private PersonDao personDao;
public void save(Person person) {
}
public IDCard getIDCare(Integer personid) {
return null;
}
public void modefy() {
Department department = new Department();
}
}
public class Department {
}
public class IDCard {
}
public class Person {
}
public class PersonDao {
}
2.2、泛化
泛化（Generalization）关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系，是 is-a 的关系。
在 UML 类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。在代码实现时，使用面向对象的继承机制来实现泛化关系。例如，Student 类和 Teacher 类都是 Person 类的子类，其类图如图 8 所示。
图8 泛化关系的实例
对应的类图：
public abstract class DaoSupport {
public void save(Object entity) {
}
public void delete(Object id) {
}
}
public class PersonServiceBean extends DaoSupport {
}
2.3、实现
实现（Realization）关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。
在 UML 类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。例如，汽车和船实现了交通工具，其类图如图 9 所示。
图9 实现关系的实例
类图如下：
public interface PersonService {
public void delete(Integer id);
}
public class PersonServiceBean implements PersonService {
@Override
public void delete(Integer id) {
// TODO Auto-generated method stub
System.out.println("delete..");
}
}
2.4、关联
关联（Association）关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。我们先介绍一般关联。
关联可以是双向的，也可以是单向的。在 UML 类图中，双向的关联可以用带两个箭头或者没有箭头的实线来表示，单向的关联用带一个箭头的实线来表示，箭头从使用类指向被关联的类。也可以在关联线的两端标注角色名，代表两种不同的角色。
在代码中通常将一个类的对象作为另一个类的成员变量来实现关联关系。图 5 所示是老师和学生的关系图，每个老师可以教多个学生，每个学生也可向多个老师学，他们是双向关联。
图5 关联关系的实例
关联关系实际上就是类与类之间的关系，是依赖关系的特例。
关联具有导航性：即双向关系或单向关系。
关联具有多重性：如“1”（表示有且仅有一个），“0...”（表示0个或多个），“0，1”（表示0个或1个），“n...m”（表示n到m个都可以）。
单向一对一关系：
public class Person {
private IDCard card;
}
public class IDCard {
}
双向一对一关系：
public class Person {
private IDCard card;
}
public class IDCard {
private Person person;
}
2.5、聚合
聚合（Aggregation）关系是关联关系的一种，是强关联关系，是整体和部分之间的关系，是 has-a 的关系。
聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如，学校与老师的关系，学校包含老师，但如果学校停办了，老师依然存在。
在 UML 类图中，聚合关系可以用带空心菱形的实线来表示，菱形指向整体。图 6 所示是大学和教师的关系图。
图6 聚合关系的实例
如：一台电脑由键盘、显示器、鼠标等组成，组成电脑的各个配件是可以从电脑上分离出的，使用带空心菱形的实线来表示。
public class Computer {
private Mouse mouse; //鼠标可以和Computer分离
private Moniter moniter;//显示器可以和Computer分离
public void setMouse(Mouse mouse) {
this.mouse = mouse;
}
public void setMoniter(Moniter moniter) {
this.moniter = moniter;
}
}
2.6、组合
组合（Composition）关系也是关联关系的一种，也表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系，是 cxmtains-a 关系。
在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。例如，头和嘴的关系，没有了头，嘴也就不存在了。
在 UML 类图中，组合关系用带实心菱形的实线来表示，菱形指向整体。图 7 所示是头和嘴的关系图。
图7 组合关系的实例
在程序中我们定义实体：Person与IDCard、Head，那么Head和Person就是组合，IDCard和Person就是聚合。
但是如果在程序中Person实体定义了对IDCard进行级联删除，即删除Person时连同IDCard一起删除，那么IDCard和Person就是组合了。
public class Person {
private IDCard card; //聚合关系
private Head head = new Head(); //组合关系
}
public class IDCard {
}
public class Head {
}
public class Computer {
private Mouse mouse = new Mouse(); //鼠标不可以和Computer分离
private Moniter moniter = new Moniter();//显示器不可以 和Computer分离
public void setMouse(Mouse mouse) {
this.mouse = mouse;
}
public void setMoniter(
Moniter moniter) {
this.moniter = moniter;
}
}
未完，请看23种设计模式-个人笔记(二)： https://mp.csdn.net/editor/html/113679456