为什么学习设计模式

设计模式： 一个设计模式描述了一个被证实可行的方案。这些方案非常普遍，是具有完整定义的最常用的模式。一般模式有4个基本要素：模式名称（pattern name）、问题（problem）、解决方案（solution）、效果（consequences）。

常见23种模式概述：

1） 抽象工厂模式（Abstract Factory）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

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

3） 桥梁模式（Bridge）：将抽象部分与它的实现部分分离，使它们都可以独立地变化。

4） 建造模式（Builder）：将一个复杂对象的构建与它的表示分离，使同样的构建过程可以创建不同的表示。

5） 责任链模式（Chain of Responsibility）：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。

6） 命令模式（Command）：将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。

7） 合成模式（Composite）：将对象组合成树形结构以表示“部分－整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。

8） 装饰模式（Decorator）：动态地给一个对象添加一些额外的职责。就扩展功能而言，它能生成子类的方式更为灵活。

9） 门面模式（Facade）：为子系统中的一组接口提供一个一致的界面，门面模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

10） 工厂方法（Factory Method）：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method 使一个类的实例化延迟到其子类。

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

12） 解释器模式（Interpreter）：给定一个语言，定义它的语法的一种表示，并定义一个解释器，该解释器使用该表示解释语言中的句子。

13） 迭代子模式（Iterator）：提供一种方法顺序访问一个聚合对象中的各个元素，而又不需暴露该对象的内部表示。

14） 调停者模式（Mediator）：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的内部表示。

15） 备忘录模式（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。

16） 观察者模式（Observer）：定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新。

17） 原始模型模式（Prototype）：用原型实例指定创建对象的种类，并且通过拷贝这个原型创建新的对象。

18） 代理模式（Proxy）：为其他对象提供一个代理以控制对这个对象的访问。

19） 单例模式（Singleton）：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

20） 状态模式（State）：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。

21） 策略模式（Strategy）：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。

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

23） 访问者模式（Visitor）：表示一个作用于某对象结构中的各元素的操作。该模式可以实现在不改变各元素的类的前提下定义作用于这些元素的新操作。

也许有人会问：“为什么要学习设计模式呢？”原因有很多，一些非常明显，而另一些则不那么明显。

学习模式最常见的理由是因为我们可以借其：

  ● 复用解决方案——通过复用已经公认的设计，我能够在解决问题时取得先发优势，而且避免重蹈前人覆辙。我可以从学习他人的经验中获益，用不着为那些总是会重复出现的问题再次设计解决方案了。

  ● 确立通用术语——开发中的交流和协作都需要共同的词汇基础和对问题的共识。设计模式在项目的分析和设计阶段提供了共同的基准点。

模式还为我们提供了观察问题、设计过程和面向对象的更高层次的视角，这将使我们从“过早处理细节”的桎梏中解放出来。

等你读完本书的时候，我希望你将同意这是学习设计模式的最重要的原因之一。它将改变你的思维定式，使你成为更加高效的分析人员。

为了说明这一优点，我想引述一段两个木匠之间关于“如何为橱柜制作抽屉”的谈话。

想像一下，有两个木匠在讨论怎样为橱柜制作抽屉。

木匠甲：你认为我们应该怎样制作这些抽屉？

木匠乙：这个嘛，我想榫子应该这样做：在木料上直着锯下去，然后向回转45°再锯，接着再直着锯，然后换一个方向45°往回锯，接着再直着锯下去，然后……

现在，你要做的就是搞清楚他们说的是什么意思！

这段描述是不是让人不知所云？木匠乙到底给出了什么建议？细节往往就是如此！让我们试着将他的叙述画出来。

这听上去像不像似曾相识的代码评审？在评审中有一位程序员这样描述自己的代码：

然后，我在这里用一个WHILE 循环来……接着是一系列IF语句执行……这里我用一条SWITCH语句处理……

你获得的是对代码细节的描述，而对“程序到底要做什么”、“为什么这么做”，你却毫无头绪!

当然，正经的职业木匠可不会这样说话。真实的情形应该是这样：

木匠甲：我们应该用鸠尾榫还是斜榫？

看到这里的本质区别没有？木匠们现在讨论的是一个问题的解决方案上的本质差异，他们的讨论层次更高、也更抽象了，从而避免了陷入具体解决方案的细节泥沼中。

当木匠谈到“斜榫”时，他的脑子里已经对这个解决方案浮现出如下特征：

  ● 它是一个更简单的解决方案——斜榫更容易制作。只需将制作榫的木料锯出45°斜面，然后用钉子或者木胶接合起来即可。

  ● 它更轻型——斜榫比鸠尾榫强度低。在重压下，将无法保持榫接。

  ● 它不太引人注目——斜榫的一个锯面，与鸠尾榫的多个锯面相比，更不显眼。

当木匠谈到“鸠尾榫”时，他的脑子里浮现出另一些特征。这些特征对外行来说可能并不明显，但任何一位木匠都会明白如故：

  ● 它是一个更复杂的解决方案——制作鸠尾榫涉及的问题更多。因此，它的成本也更高。

  ● 它不容易受温度和湿度影响——当温度和湿度变化时，木材会膨胀或收缩，但是，鸠尾榫仍然能够保持坚固。

  ● 它与紧固系统无关——事实上，鸠尾榫甚至不需要依赖胶水。

  ● 它看上去更赏心悦目——如果制作精良，会很美观。

也就是说，鸠尾榫是一个坚固、可靠、美观的榫，但制作复杂（所以成本也比较高）。

所以，当木匠甲这样问的时候：

我们应该用鸠尾榫还是斜榫？

他真正要问的问题是：

我们是应该用一个制作昂贵但美观耐用的榫，还是应该只用一个制作快速而且不美观的榫，能坚持到检查结束就行？

我们应该说，木匠们的讨论其实是在两个层次上进行的：他们话语表面上的层次，和谈话真正的内容，层次更高，外行听不出来，而其中含义却非常丰富。这种更高的层次就是“木匠模式”的层次，它反映了木匠眼中的真正的设计问题。

在第1种情形中，木匠乙讨论的是榫的实现细节，反而使真正的问题模糊不清。在第2种情形中，木匠甲要根据榫的成本和接合性质来决定使用哪种榫。

    谁更有效率呢？你更愿意与谁一起工作？