feat: finish head first设计模式

Author: Uyouii

设计模式/Head First设计模式(第二版).md

@@ -153,6 +153,117 @@ func GetInstance() *Singleton {
 
 反模式告诉你如何从问题到达一个坏的解决方案。
 
+## 14 剩下的模式
+
+### 桥接(Bridge)
+
+使用桥接模式不知改变你的实现，也改变你的抽象。
+
+**优缺点：**
+
+| 优点                                   | 用途和缺点                                         |
+| -------------------------------------- | -------------------------------------------------- |
+| 解耦实现，不再永久绑定到接口           | 在跨多个平台的图形和窗口系统中很有用。             |
+| 抽象和实现可以独立扩展                 | 当你需要以不同的方式改变接口和实现时，桥接很好用。 |
+| 针对“具体的抽象类”的变化，不会影响客户 | 缺点是增加了复杂度。                               |
+
+### 生成器(Builder)
+
+使用生成器模式来封装一个产品的构造过程，并允许按步骤构造。
+
+**优缺点：**
+
+| 优点                                                         | 用途和缺点                                       |
+| ------------------------------------------------------------ | ------------------------------------------------ |
+| 封装复杂对象的构造方式                                       | 经常被用来建造组合结构                           |
+| 允许对象用多个步骤构造，并且可以改变过程（和一步到位的工厂不同） | 和使用工厂相比，构造对象需要更多客户的领域知识。 |
+| 向客户隐藏产品的内部表现                                     |                                                  |
+| 产品的实现可以被替换，因为客户只看到抽象的接口               |                                                  |
+
+### 责任链(Chain)
+
+当你要把一个处理请求的机会给予多余一个的对象时，使用责任链模式。
+
+**优缺点：**
+
+| 优点                                                         | 用途和缺点                                                   |
+| ------------------------------------------------------------ | ------------------------------------------------------------ |
+| 解耦请求的发送者和接收者                                     | 经常用在窗体系统中，处理鼠标点击和键盘事件。                 |
+| 简化你的对象，因为它不需要知道链的结构以及保持对其成员的直接引用 | 并不保证请求一定会被执行；如果没有对象处理它，可能会掉到链的末尾（这可以是优点或缺点） |
+| 允许你通过改变链的成员或次序，动态地添加或移除责任。         | 运行时可能会难以观察和调试                                   |
+
+### 蝇量(Flyweight)
+
+当某个类的一个实例可以用于提供许多虚拟实例时，使用蝇量模式。
+
+**优缺点：**
+
+| 优点                                   | 用途和缺点                                                   |
+| -------------------------------------- | ------------------------------------------------------------ |
+| 减少运行时对象实例的树木，节省内存     | 当一个类有许多实例，而这些实例能够用一致的方法控制时，用蝇量。 |
+| 把许多“虚拟”对象的状态集中放进一个地方 | 蝇量模式的一个缺点在于，一旦你实现了它，那么类的单个逻辑实例，将无法拥有和其他实例不同的独立行为。 |
+
+### 解释器(Interpreter)
+
+使用解释器模式为语言建造解释器。
+
+**优缺点：**
+
+| 优点                                                         | 用途和缺点                                                   |
+| ------------------------------------------------------------ | ------------------------------------------------------------ |
+| 将每一个语法规则表达成一个类，使得语言容易实现               | 当你需要实现一门简单的语言时，使用解释器                     |
+| 因为语法由类表达，你可以轻易地改变或扩展该语言               | 当你有一个单间的语法，而且简单比效率重要时，适合用解释器     |
+| 通过在类结构中添加方法，可以添加解释之外的新行为，例如打印格式的美化和更复杂的程序验证。 | 用于脚本和编程语言                                           |
+|                                                              | 当语法规则的数目很大时，这个模式可能变得笨重。在这些情况下，一个解析器/编译器的生成器可能更适合。 |
+
+### 中介者(Mediator)
+
+使用中介者模式来集中相关对象之间复杂的沟通和控制方式。
+
+**优缺点：**
+
+| 优点                                                   | 用途和缺点                                                   |
+| ------------------------------------------------------ | ------------------------------------------------------------ |
+| 通过将中介者支持的对象从系统中解耦，增加对象的复用性。 | 中介者常用于协调相关的GUI组件                                |
+| 通过将控制逻辑集中，简化了系统的维护。                 | 中介者模式的一个缺点是，如果设计不当，中介者对象本身会变得过度复杂。 |
+| 简化以减少系统中对象之间发送的消息的变化。             |                                                              |
+
+### 备忘录(Memento)
+
+当你需要让对象返回之前的某个状态时，例如，你的用户请求“撤销”，使用备忘录模式。
+
+**优缺点：**
+
+| 优点                                             | 用途和缺点                                                   |
+| ------------------------------------------------ | ------------------------------------------------------------ |
+| 保持被保存的状态处于关键对象外面，有助于维护内聚 | 备忘录用于保持状态                                           |
+| 保持关键对象的数据封装                           | 使用备忘录的一个缺点是，保存和恢复状态可能相当耗时           |
+| 提供容易实现的恢复能力                           | 在Java系统中，考虑使用序列化(Serialization)来保存系统的状态。 |
+
+### 原型(Prototype)
+
+当创建给定类的实例昂贵或者复杂时，使用原型模式。
+
+**优缺点：**
+
+| 优点                                     | 用途和缺点                                                   |
+| ---------------------------------------- | ------------------------------------------------------------ |
+| 向客户隐藏制作新实例的复杂性             | 在一个复杂的类层次中，当系统必须创建许多类型的新对象时，应该考虑原型。 |
+| 提供一种选择，让客户生成类型未知的对象   | 使用原型的缺点是，对象的复制有时候相当复杂。                 |
+| 在某些环境下，复制对象比创建新对象更有效 |                                                              |
+
+### 访问者(Visitor)
+
+当你想要为一个对象组合增加能力，且封装不重要时，使用访问者模式。
+
+**优缺点：**
+
+| 优点                                       | 用途和缺点                                       |
+| ------------------------------------------ | ------------------------------------------------ |
+| 允许你添加操作到组合结构，而不改变结构本身 | 使用访问者模式时，组合类的封装被打破             |
+| 添加新操作相对容易                         | 因为涉及到导游的功能，因此组合结构更加难以变化。 |
+| 由访问者执行的操作的代码被集中化了         |                                                  |
+
 ## 附录
 
 1. [The Porland Patterns Repository](http://c2.com/cgi/wiki?WelcomeVisitors)