设计模式（一）：分类、类图关系、设计原则

一、设计模式的分类

1、根据目的来分

根据模式是⽤来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式三大类。

• 创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使⽤用 分
  离”。GoF中提供了单例、原型、工厂方法、抽象⼯厂、建造者等 5 种创建型模式。

• 结构型模式：⽤于描述如何将类或对象按某种布局组成更更大的结构，GoF中提供了
  代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。

• 行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完
  成的任务，以及怎样分配职责。GoF 中提供了了模板方法、策略、命令、职责链、状
  态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。

2、根据作用范围来分

根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式

• 类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在
  编译时刻便确定下来了。GoF中的工厂方法、（类）适配器、模板方法、解释器属于
  该模式。

• 对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运
  行时刻是可以变化的，更具动态性。GoF 中除了以上4种，其他的都是对象模式。
  下表介绍了这 23 种设计模式的分类。

范围目的	创造型模式	结构型模式	行为型模式
类模式	工厂方法	（类）适配器	模板方法 解释器
对象模式	单例 原型 抽象工厂 建造者	代理（对象） 适配器 桥接 装饰 外观 享元 组合	策略 命令 职责链 状态 观察者 中介者 迭代器 访问者 备忘录

3、GoF的23种设计模式的功能

前面说明了GoF的23种设计模式的分类，现在对各个模式的功能进行介绍。

1. 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。

2. 原型（Prototype）模式：将一个对象作为原型，通过对其进⾏复制而克隆出多个和原型类似的新实例。

3. ⼯厂⽅法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产 什么产品。

4. 抽象工厂（Abstract Factory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。

5. 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。

6. 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。

7. 适配器（Adapter）模式：将⼀个类的接口转换成客户希望的另外一个接口，使得原本由于接口不不兼容而不能一起工作的那些类能一起⼯作。

8. 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从⽽而降低了抽象和实现这两个可变维度的耦合度。

9. 装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。

10. 外观（Facade）模式：为多个复杂的子系统提供⼀个⼀致的接口，使这些子系统更加容易被访问。

11. 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。

12. 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

13. 模板方法（Template Method）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。

14. 策略（Strategy）模式：定义了了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。

15. 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。

16. 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。

17. 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。

18. 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。

19. 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。

20. 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

21. 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。

22. 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。

23. 释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

必须指出，这 23 种设计模式不是孤立存在的，很多模式之间存在一定的关联关系。

4、UML中的类图及类图之间的关系

4.1、什么是UML

统一建模语言（Unified Modeling Language，UML）是⽤用来设计软件蓝图的可视化建模语言，1997
年年被国际对象管理组织（OMG）采纳为面向对象的建模语言的国际标准。
统一建模语⾔言能为软件开发的所有阶段提供模型化和可视化支持。而且融入了软件工程领域的新思想、新方法和新技术，使软件设计人员沟通更简明，进一步缩短了设计时间，减少开发成本。它的应⽤用领域很宽，不仅适合于一般系统的开发，而且适合于并行与分布式系统的建模。

4.2、类、接口和类图

• 类：具有相同属性、方法和关系的对象的抽象，他封装了数据和行为，是面向对象程序设计（OOP）的基础，具有封装性、继承性和多态性等三大特性。在UML中，类使用包含类名、属性和操作且带有分割线的矩形来表示。如图是学生类的UML表示：
  

• 接口：是一种特殊的类，具有类的结构但是不能被实例化，只可以被子类实现，他包括抽象属性，他描述了类和组件对外可见的动作，在UML中， 接口使用一个带有名称的小圆圈来进行表示，下图为图形类的接口的UML表示：
  

• 类图（Class Diagram）是用来显示系统中的类、接口、协作以及他们的静态结构和关系的一种静态模型，他主要用于描述软件系统的结构化设计，帮助人们简化对于软件系统的理解，他是系统分析与设计阶段的重要产物，也是系统编码与测试的重要模型依据，类图中的类可以通过某种编程语言直接实现，类图在软件系统开发的整个生命周期都是有效的，他是面向对象系统的建模中最常见，下图所示的是“计算长方形和圆形的周长与面积”的类图，图形接口有计算面积和周长的抽象方法，长方形和圆形实现这两个方法供访问类调用。
  

4.3、类之间的关系

在软件系统中，类不是孤⽴立存在的，类与类之间存在各种关系。根据类与类之间的耦合度从弱到强排列，UML中的类图有以下几种关系：依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。

• 依赖关系

依赖（Dependency）关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的⽅方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。

在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。

• 关联关系

关联（Association）关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。我们先介绍一般关联。 关联可以是双向的，也可以是单向的。在 UML 类图中，双向的关联可以用带两个箭头或者没有箭头的实线来表示，单向的关联用带一个箭头的实线来表示，箭头从使用类指向被关联的类。也可以在关联线的两端标注角色名，代表两种不同的⻆色。

• 聚合关系

聚合（Aggregation）关系是关联关系的一种，是强关联关系，是整体和部分之间的关系，是has-a 的关系。 聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如，学校与老师的关系，学校包含老师，但如果学校停办了了，老师依然存在。

• 组合关系

组合（Composition）关系也是关联关系的一种，也表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系，是 cxmtains-a 关系。 在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。例如，头和嘴的关系，没有了头，嘴也就不存在了。

• 泛化关系

泛化（Generalization）关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系，是 is-a 的关系。 在 UML类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。在代码实现时，使用面向对象的继承机制来实现泛化关系。例如，Student 类和 Teacher类都是Person 类的子类，其类图如下图所示：

• 实现关系

实现（Realization）关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了了接口中所声明的所有的抽象操作。 在 UML 类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。例如，汽车和船实现了交通工具，其类图如下图所示：

5、面向对象的设计原则

在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据 7 条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。

5.1、开闭原则

开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶（Bertrand Meyer）提出，他在1988 年的著作《面向对象软件构造》（Object Oriented So!ware Construction）中提出：软件实体应当对扩展开放，对修改关闭（So!ware entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。

开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

开闭原则的实现方法：

可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。 因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

5.2、里氏替换原则

里氏替换原则（Liskov Substitution Principle，LSP）由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立（Inheritance should ensure that any property proved about super type objects also holds for subtype objects）。

里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。

里氏替换原则的主要作用如下：

• 是实现开闭原则的重要方式之一；
• 他克服了继承中重写父类造成的可复用性变差的缺点；
• 他是动作正确性的保证，即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

里氏替换原则的实现方式：

子类可以扩展父类的功能，但不能改变父类原有的功能 。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会较差，特别是运⽤用多态比较频繁时，程序运行出错的概率会非常大。如果程序违背了了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。

5.3、依赖倒置原则

依赖倒置原则（Dependence Inversion Principle，DIP）是 Object Mentor 公司总裁罗伯特·马丁（Robert C. Martin）于1996 年在 Report 上发表的文章。

依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules should not depend upon low level modules .Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程。

依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。

依赖倒置原则的作用：

• 可以降低类之间的耦合性；
• 可以提高系统的稳定性；
• 可以减少并行开发引起的风险；
• 可以提供代码的可读性和可维护性。

依赖倒置原则的实现方法：

依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。

• 每个类尽量提供接口或抽象类，或者两者都具备；

• 变量的声明类型尽量是接口或者是抽象类；

• 任何类都不应该从具体类派生；

• 使用继承时尽量遵循里氏替换原则。

5.4、单一职责原则

单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。

• 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
• 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从⽽而造成冗余代码或代码的浪费。

单一职责原则的作用：

单一职责原则的核心就是控制类的粒度⼤小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

• 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
• 提⾼类的可读性。复杂性降低，自然其可读性会提高。
• 提高系统的可维护性。可读性提高，那自然更更容易维护了。
• 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

单一职责原则的实现方法：

单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

注意：单一职责同样也适⽤用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。

5.5、接口隔离原则

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）。 以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。

• 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离；
• 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

接口隔离原则的作用：是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。

• 将臃肿庞⼤大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性；
• 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性；
• 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险；
• 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义；
• 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，*设计冗余的代码。

接口隔离原则的实现方法：

在具体应用接口隔离原则时，应该根据以下几个规则来衡量。

• 接口尽量量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
• 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
• 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的
  标准就不同深入了解业务逻辑。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

5.6、迪米特法则

迪米特法则（Law of Demeter，LoD）又叫作，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。
迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌⽣生人”说话（Talk only to your
immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

迪米特法则的作用：迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下2个优点。

• 降低了类之间的耦合度，提高了模块的相对独立性；
• 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

迪米特法则的实现方式：从迪米特法则的定义和特点可知，它强调以下两点：

• 从依赖者的⻆角度来说，只依赖应该依赖的对象。

• 从被依赖者的角度说，只暴露应该暴露的方法。

所以，在运用迪米特法则时要注意以下 6 点：

• 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标；
• 在类的结构设计上，尽量降低类成员的访问权限；
• 在类的设计上，优先考虑将一个类设置成不变类；
• 在对其他类的引用上，将引用其他对象的次数降到最低；
• 不暴露类的属性成员，而应该提供相应的访问器（set和 get 方法）；
• 谨慎使用序列化（Serializable）功能。

5.7、合成复用原则

合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

合成复用原则的作用：

通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点：

• 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子
  类是透明的，所以这种复用又称为“白箱”复用。
• 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这
  不利于类的扩展与维护。
• 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点：

• 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用；
• 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口；
• 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

合成复用原则的实现方法：

合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。 下面以汽车分类管理程序为例来介绍合成复用原则的应用。