一、总论
设计模式是一个工程问题，它不能为某个问题提供具体的答案，它只能让答案写得好看一些。
更进一步地说，设计模式是用于解决代码复杂度高（不是算法复杂度）的问题，这会引发难以阅读，难以维护等伴生问题。当代码量小，复杂度低，没有什么维护需求的时候（比如说科研代码），其实是没有必要采用规范的设计模式的。
我个人学习设计模式，并不是为了写代码（因为我写的代码就是科研代码），而是为了更好的阅读代码，因为大型工程代码都会或多或少遵循设计模式的思路。
很多设计模式解决的复杂度问题，是客观存在的，认识这些问题有助于设计出更加简洁健壮的架构；但是有些问题可能只是类似 Java 等语言表述能力不够所导致的，不用太较真。
二、设计原则
设计原则的目的同样是降低代码的复杂度。它可以看作是设计模式的“基本原理”，每个设计模式都或多或少贯彻了这些原则。
我们会介绍一些这些原则的具体内容，并简单描述一下这些原则是如何发挥作用的。总的来说，它们都是在描述“一个好的抽象”或者说“一个好的接口”，应该具有哪些性质（简洁、稳定、精妙、短小）。
2.1 单一职责原则
单一职责原则（Single Responsibility Principle）指的是每一个类仅负责一项职责，当然如果更普适一些的表述，是每一个代码模块（OOP 中的类，某个函数，某个库）只负责一项职责。
这是因为当代码模块以“功能”为单位划分的时候，就符合了“高内聚，低耦合”的思想，每个模块其实以一个抽象职责的实现。代码开发者通过付出“冥思苦想提炼抽象”的代价，获得了“模块化”的优势。
当我们说“六大原则”的时候，其实是将单一职责原则剔除的，是因为这个原则在语义表述上，一点也不“单一职责”，它的思想
2.2 开闭原则
开闭原则（Open Close Principle）指的是代码需要保证对于拓展开发，而对于修改关闭。说白了，就是只能增加功能，不能删除和修改功能。
代码开发者通过付出“维护一个可能更大且更冗余的代码量”的代价，获得了“向后兼容性”的优势。如何尽量规避这种代价呢？那就需要在设计之初，就尽可能避免设计出一些稳定性不强、可发展性不强的接口，避免日后为了维持这个接口而付出过大的代价。
2.3 里氏代换原则
里氏代换原则（Liskov Substitution Principle, LSP）指的是任何基类可以出现的地方，子类一定可以出现。也就是说，基类和子类是“接口-实现”的关系。
里氏规则明确了接口和实现的分离关系，这样无论实现怎么变化（多种接口），接口都可以保持稳定。
里氏规则要求写出来的代码遵循这样的一种原则“如果鸟（基类）是会飞的，鸵鸟是一种鸟，那么鸵鸟就应该会飞”。而不幸的是，鸵鸟真的不会飞。所以基类（其实就是接口）的实际人员，就要避免给接口设计出像“飞”这样的非普适功能，或者避免将“鸵鸟”加入“鸟类”。
2.4 依赖倒置原则
所谓的依赖倒置，就是一个代码模块，是它的接口决定了它如何实现，而不是它的实现决定了它的接口。实现依赖接口，而非反过来。
这是因为实现细节具有多变性，而接口需要相对稳定。
2.5 接口隔离原则
接口隔离原则（Interface Segregation Principle）指的是接口之间的功能都要彼此隔离而不是耦合在一起（其实也是单一职责原则的一种体现）。这是因为耦合对于维护是不利的，耦合会让依赖增多。
2.6 最小知道原则
最小知道原则（Demeter Principle）指的是一个接口应该与尽量少的其他接口发生相互作用。也是减少依赖的方式。
2.7 合成复用原则
合成复用原则（Composite Reuse Principle）指的是要尽量使用组合的方式来拓展功能，而不是采用继承的方式拓展功能。因为继承方式在某种意义上，是将基类形成了一种接口，而有些基类并没有经过良好的设计（它实现的时候是别人的子类），这种继承会引入性质不优良的接口。
而组合只是拓展了功能，并没有引入新的抽象。
三、设计模式
正如前所述，设计模式是针对特定场景来优化代码复杂度的方案，也就是哪里复杂了，哪里才需要设计模式。设计模式可以分成“创建型，结构型，行为型”三类，分别对应一个模块在创建时、静态结构上、动态运行逻辑上产生复杂度时的应对方案。
3.1 创建型模式
3.1.1 工厂方法
工厂方法解决的问题是，对于一个普通的对象创建，我们一般直接调用构造器方法，而这种方式有时的表达能力是不够强的。
比如说对于很多常量，我们并不需要每次都创建一个新的对象，我们可以共享对象，反正没人可以修改这些共享对象。但是只要一调用构造器，那么就会产生一个新的对象。再比如，我们希望采用批处理的形式构造对象，那么使用构造器就没有办法做到。
为了实现这些更多的语义，一个比较自然的想法就是在创建对象的上下文中加上一些代码，但是因为对象的创建可能弥散在各个地方，这些代码也会被复制很多份，就很复杂。所以更好的方法就是定义一个“工厂方法”，将这些语义集成进去，就更好维护了。
我觉得工厂方法是唯一值得介绍的创建型方法，因为只有它在将复杂的构造代码提炼出一个新的抽象。其他模式都可以看作是在工厂方法上做出的改进。
3.1.2 抽象工厂
也就是存在多个工厂，这些工厂有一个共同的父类“抽象工厂”，这样我们就可以用不同的工厂（相当于具体的实现）来实现不同的构造策略。
3.1.3 生成器
它指的是将构造过程拆分成多个步骤，每个步骤使用一个工厂方法。这种方法的好处除了可以让代码模块更加小以外，也更加灵活了。我们可以通过组合不同的工厂，来满足比较复杂的构造需求。
比如说对于“两轮车，三轮车，四轮车”的生产，我们可以简单的构造“两轮车工厂，三轮车工厂，四轮车工厂”。当然我们也可以只维护“车壳工厂”和“车轮工厂”两个工厂来满足这种复杂的构造需求。
生成器本质是对于构造功能的解耦和自由组合。
3.1.4 原型
当我们存在复制一个对象的需求的时候，其实是有两种思路的，方案 1 ：
class A {
int x;
int y;
};
A a, b;
// copy a to b
b.x = a.x;
b.y = a.y;这种方案是有复制需求的一方在完成复制过程。
方案 2 :
class A {
int x;
int y;
class A clone() {
A b;
b.x = this->x;
b.y = this->y;
}
};
A a;
A b = a.clone();这种方案是有复制需求的一方只是调用 clone 方法，具体的方式是交给原型来做的。
当这种复制操作比较多的时候，显然第二种方式就比较好了；此外，当被复制的一方有私有数据时，也是第二种方式比较好。
3.1.5 单例
就是全局只有一个对象的情况，其实是和 Java 具体的语法联系比较紧密了，没有什么设计上的借鉴价值。
3.2 结构型模式
3.2.1 适配器
适配器模式是 Adapter，也称 Wrapper，是指如果一个接口需要 B 接口，但是待传入的对象却是 A 接口，怎么办？
那么就在 A 外面套一层满足 B 接口的适配器就可以了。
3.2.2 桥接
其实这个模式很简单，它就是我们理解的“组合”，也就是每个部分只负责一些小的互相独立的功能，利用多个独立功能来组合完成复杂功能。
但是我很喜欢 Bridge 的概念，桥似乎在计算机术语中，描述的就是一种将多个功能模块组合在一起的概念，比如说芯片中的南桥和北桥芯片，网络中的桥接模式。
它更像是一种“中间人”或者“平台”的概念，与汉语中的“连接和沟通两地”的概念有些出入。
3.2.3 组合
这里说的组合并不是和“继承”有对立关系的那个“组合”，而是一种树形结构，并且采用了递归处理：
public interface Node {
private String name;
private List<Node> list = new ArrayList<>();
public String toXml() {
String start = "<" + name + ">\n";
String end = "</" + name + ">\n";
StringJoiner sj = new StringJoiner("", start, end);
list.forEach(node -> {
sj.add(node.toXml() + "\n");
});
return sj.toString();
}
}总的来说就是树形结构的那些优点呗，局部的，递归的。
3.2.4 装饰器
装饰器（Decorator）模式，是一种在运行期动态给某个对象的实例增加功能的方法。
从实践角度来说，一些功能可能并不适合集成到类内部。比如说对某个类的“机械打印方法”，就是打印这个类的所有数据域（用于 debug）。这种方法显然不适合在类内部实现，不然每个类都要有这样的一个愚蠢的方法了。
所以我们可以将这个打印功能单独抽离出来，然后加到（装饰）所需要的类上，至于加的方法是基类、元编程还是什么其他手段，这就因实现而定了。
3.2.5 外观
外观模式，即 Facade ，它指的是：如果客户端要跟许多子系统打交道，那么客户端需要了解各个子系统的接口，比较麻烦。如果有一个统一的“中介”，让客户端只跟中介打交道，中介再去跟各个子系统打交道，对客户端来说就比较简单。
3.2.6 享员
享元（Flyweight）的核心思想很简单：如果一个对象实例一经创建就不可变，那么反复创建相同的实例就没有必要，直接向调用方返回一个共享的实例就行，这样即节省内存，又可以减少创建对象的过程，提高运行速度。
3.2.7 代理
代理模式，即 Proxy 。它和 Adapter 模式很类似，它们都是在原有类上在封装一层。
我个人觉得区别是，Adapter 是为了让功能可以正常使用，而 Proxy 视为了拓展功能的使用。比如说工厂方法就可以看作是构造方法的一种代理。
3.3 行为型模式
3.3.1 责任链
行为型模式都是为了解决复杂的业务流而提出的。责任链的概念有些类似于流水线，每个人只负责处理一小部分业务逻辑。我个人感觉其实它更像是一堆筛网的集合，液体从中流过，滤出去了不同的东西。
这种模式下，增添一个筛网或者调整筛网的顺序，都是非常容易的，我甚至品出了流处理的精神。
3.3.2 命令模式
这说的是，对于每个操作，我们都让他们继承自一个叫做 Command 的基类，这样我们就可以对于这些操作进行统一的管理，比如我们可以 undo, redo 这些操作，至于我们为什么要对于这些操作进行统一的管理，可能这就是具体的情景要求了（比如一个编辑器中这种操作很常见）。
我个人觉得这种思想其实有些类似于“事务”或者“函数式”的思想了，将一段可执行代码当成一个类来操作。
3.3.3 解释器
其实就是对于一些特定的问题，通用的编程语言会存在冗余繁复等问题，所以可以开发 DSL 来描述业务。解释器说的就是 DSL 的方法。
那么 DSL 的解释器的开发和维护难度呢？我觉得肯定是比不开发要难的，那我们为什么还需要 DSL 呢？我觉得是因为业务逻辑本身十分复杂且有规律，所以我们将原本的“业务逻辑复杂度”拆分成了“DSL 代码复杂度 + DSL 解释器复杂度”两个部分，或许这种拆分要比之前的复杂度要低。
3.3.4 迭代器
迭代器在 C++ Primer 中已经讨论滥了，它忽略了不同数据结构之间的差异，让我们可以以统一的方式遍历不同数据结构中的元素。也就是说，这是一种对于“迭代”这个操作的统一抽象。
3.3.5 中介
中介模式（Mediator）是通过引入一个中介对象，把多边关系变成多个双边关系，从而简化系统组件的交互耦合度。
说穿了，中介就是一个全局看板。
3.3.6 备忘录
备忘录模式（Memento），主要用于捕获一个对象的内部状态，以便在将来的某个时候恢复此状态。
我是觉得它和“原型”差不多。
3.3.7 观察者
我觉得就是发布-订阅模式，是一种一对多的通知机制，使得双方无需关心对方，只关心通知本身。
3.3.8 状态
状态模式类似于状态机的理念，也就是根据状态产生不同的行为。
在具体的代码实现中，有一个 State 基类，它定义了一个 process() 纯虚方法，不同的状态继承这个基类并覆盖了 process 方法。
3.3.9 策略
策略模式：Strategy，是指，定义一组算法，并把其封装到一个对象中。然后在运行时，可以灵活的使用其中的一个算法。
3.3.10 模板方法
模板方法（Template Method）是一个比较简单的模式。它的主要思想是，定义一个操作的一系列步骤，对于某些暂时确定不下来的步骤，就留给子类去实现好了，这样不同的子类就可以定义出不同的步骤。
因此，模板方法的核心在于定义一个“骨架”。
3.3.11 访问者
访问者模式（Visitor）是一种操作一组对象的操作，它的目的是不改变对象的定义，但允许新增不同的访问者，来定义新的操作。
有一说一非常复杂，我看懂了，但是我觉得没有什么特殊的。