面向对象之设计模式的概述
一、设计模式的简介
1.1 设计模式的起源与发展
设计模式的灵感源于建筑领域。1977年，Christopher Alexander在《A Pattern Language》中提出253个建筑模式，强调“环境条件 - 目标问题 - 解决方案”的通用范式。1994年，GoF（四人组）将模式思想引入软件工程，出版《设计模式：可复用面向对象软件的基础》，总结23种经典模式（不包含简单工厂模式），奠定了现代软件设计的基础。
1.2 设计模式的定义
设计模式是前辈们对面向对象编程设计中反复出现的问题总结的一套解决方案，是一种共享专家设计经验的总结。
1.3 设计模式的基本要素
设计模式一般包含模式名称、问题、目的、解法（解决方案）、效果、实例代码和相关设计模式等基本要素，其中4大关键要素如下：
- 名称：前辈们对不同的问题、解法以及效果总结所定义的名称，便于用户理解和交流。
- 问题：描述在什么情况下使用模式，包含存在的问题和问题存在的原因。
- 解法：描述设计模式的组成成分，以及这些组成成分之间的相互关系、各自的职责和协作方式。
- 效果：描述模式的应用情况以及使用模式时应该权衡的问题。
1.4 设计模式的分类
根据范围分类
- 类模式：用于处理类与类之间的关系，这些关系通过继承建立，在编译时就被确定下来，是一种静态关系。
- 对象模式：用于处理对象间的关系，这些关系在运行时变化，是一种动态关系。
根据目的分类
- 创建型模式：主要用于创建对象。
- 结构型模式：主要用于处理类或对象的组合。
- 行为型模式：主要用于描述类或对象如何交互和怎样分配职责。
| 范围\目的 | 创建型模式 | 结构型模式 | 行为型模式 |
|---|---|---|---|
| 类模式 | 工厂方法模式 | （类）适配器模式 | 解释器模式 模板方法模式 |
| 对象模式 | 抽象工厂模式 建造者模式 原型模式 单例模式 |
（对象）适配器模式 桥接模式 组合模式 装饰模式 外观模式 享元模式 代理模式 |
职责链模式 命令模式 迭代器模式 中介者模式 备忘录模式 观察者模式 状态模式 策略模式 访问者模式 |
二、创建型设计模式
创建型模式关注对象的创建过程，描述如何将对象的创建和使用分离，让用户在使用对象时无需关心对象的创建细节，从而降低系统的耦合度，使设计方案更易于修改和扩展。
创建型模式对类的实例化过程进行了抽象，将软件模块中对象的创建和对象的使用分离，对用户隐藏了类的实例创建细节。
每一个创建型模式都通过采用不同的解决方案来回答3个问题：
- 创建什么（What）
- 由谁创建（Who）
- 何时创建（When）
| 模式名称 | 定义 | 学习难度 | 使用频率 |
|---|---|---|---|
| 简单工厂模式 (Simple Factory Pattern) |
定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。 | ★★☆☆☆ | ★★★☆☆ |
| 工厂方法模式 (Factory Method Pattern) |
定义一个用于创建对象的接口，但是让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。 | ★★☆☆☆ | ★★★★★ |
| 抽象工厂模式 (Abstract Factory Pattern) |
提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。 | ★★★★☆ | ★★★★★ |
| 建造者模式 (Builder Pattern) |
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 | ★★★★☆ | ★★☆☆☆ |
| 原型模式 (Prototype Pattern) |
使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象。 | ★★★☆☆ | ★★★☆☆ |
| 单例模式 (Singleton Pattern) |
确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例。 | ★☆☆☆☆ | ★★★★☆ |
三、结构型设计模式
结构型模式(Structural Pattern)关注如何将现有类或对象组织在一起形成更加强大的结构。不同的结构型模式从不同的角度组合类或对象，在尽可能满足各种面向对象设计原则的同时，为类或对象的组合提供一系列巧妙的解决方案。
类结构型模式关心类的组合，由多个类组合成一个更大的系统，在类结构型模式中一般只存在继承关系和实现关系。
对象结构型模式关心类与对象的组合，通过关联关系，在一个类中定义另一个类的实例对象，然后通过该对象调用相应的方法。
| 模式名称 | 定义 | 学习难度 | 使用频率 |
|---|---|---|---|
| 适配器模式 (Adapter Pattern) |
将一个类的接口转换成客户希望的另一个接口。适配器模式让那些接口不兼容的类可以一起工作。 | ★★☆☆☆ | ★★★★☆ |
| 桥接模式 (Bridge Pattern) |
将抽象部分与它的实现部分解耦，使得两者都能够独立变化。 | ★★★☆☆ | ★★★☆☆ |
| 组合模式 (Composite Pattern) |
组合多个对象形成树形结构，以表示具有部分 - 整体关系的层次结构。组合模式让客户端可以统一对待单个对象和组合对象。 | ★★★☆☆ | ★★★★☆ |
| 装饰模式 (Decorator Pattern) |
动态地给一个对象增加一些额外的职责。就扩展功能而言，装饰模式提供了一种比使用子类更加灵活的替代方案。 | ★★★☆☆ | ★★★☆☆ |
| 外观模式 (Facade Pattern) |
为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 | ★☆☆☆☆ | ★★★★★ |
| 享元模式 (Flyweight Pattern) |
运用共享技术有效地支持大量细粒度对象的复用。 | ★★★★☆ | ★☆☆☆☆ |
| 代理模式 (Proxy Pattern) |
给某一个对象提供一个代理或占位符，并由代理对象来控制对原对象的访问。 | ★★★☆☆ | ★★★★☆ |
四、行为型设计模式
行为型模式(Behavioral Pattern)关注系统中对象之间的交互，研究系统在运行时对象之间的相互通信与协作，进一步明确对象的职责。即行为型模式不仅关注类和对象本身，还重点关注它们之间的相互作用和职责划分。
类行为型模式使用继承关系在几个类之间分配行为，主要通过多态等方式来分配父类与子类的职责。
对象行为型模式使用对象的关联关系来分配行为，主要通过对象关联等方式来分配两个或多个类的职责。
| 模式名称 | 定义 | 学习难度 | 使用频率 |
|---|---|---|---|
| 职责链模式 (Chain of Responsibility Pattern) |
避免将一个请求的发送者与接收者耦合在一起，让多个对象都有机会处理请求。将接收请求的对象连接成一条链，并且沿着这条链传递请求，直到有一个对象能够处理它为止。 | ★★★☆☆ | ★★☆☆☆ |
| 命令模式 (Command Pattern) |
将一个请求封装为一个对象，从而让你可以用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销的操作。 | ★★★☆☆ | ★★★★☆ |
| 解释器模式 (Interpreter Pattern) |
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。 | ★★★★★ | ★☆☆☆☆ |
| 迭代器模式 (Iterator Pattern) |
提供一种方法顺序访问一个聚合对象中的各个元素，且不用暴露该对象的内部表示。 | ★★★☆☆ | ★★★★★ |
| 中介者模式 (Mediator Pattern) |
定义一个对象来封装一系列对象的交互。中介者模式使各对象之间不需要显式地相互引用，从而使其耦合松散，而且让你可以独立地改变它们之间的交互。 | ★★★☆☆ | ★★☆☆☆ |
| 备忘录模式 (Memento Pattern) |
在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。 | ★★☆☆☆ | ★★☆☆☆ |
| 观察者模式 (Observer Pattern) |
定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象都得到通知并被自动更新。 | ★★★☆☆ | ★★★★★ |
| 状态模式 (State Pattern) |
允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。 | ★★★☆☆ | ★★★☆☆ |
| 策略模式 (Strategy Pattern) |
定义一系列算法，将每一个算法封装起来，并让它们可以相互替换，策略模式让算法可以独立于使用它的客户变化。 | ★☆☆☆☆ | ★★★★☆ |
| 模板方法模式 (Template Method Pattern) |
定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类不改变一个算法的结构即可重定义该算法的某些特定步骤。 | ★★☆☆☆ | ★★★☆☆ |
| 访问者模式 (Visitor Pattern) |
表示一个作用于某对象结构中的各个元素的操作。访问者模式让你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。 | ★★★★☆ | ★☆☆☆☆ |