《大话设计模式》部分模式总结（二）

9.建造者模式：

   千万个饭店，千万不同味道的鱼香肉丝，但是千万个肯德基，却只有一种味道。由此程杰老师引出了这一模式--建造者模式。建造者模式，也就是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

   利用建造者模式，用户只需指定需要建造的类型就可以得到它们，而具体建造的过程和细节就不需要知道了。简单来说，建造者模式是在当创建复杂对象的算法应该独立于该对象的组成部分以及它们的庄派方式时适用的模式。

10.观察者模式：

   老板回来了，我却不知道，依然在浏览网页，看股票，于是。。。这种情形就是程杰老师说的典型的观察者模式。观察者模式就是让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，是它们能够自动更新自己。简单的说，就是一种一对多的依赖关系。

   观察者模式是依赖倒转原则的最佳体现，它所做的工作就是解除耦合，让耦合的双方都依赖抽象，而不是依赖具体。

   当然了，在某些情况下，我们是不可能用接口的方式来实现观察者模式的，那该怎么办呢？这就涉及到了委托。

   委托就是一种引用方法的类型，一旦为委托分配了方法，委托将与该方法具有完全相同的行为。委托方法也具有参数和返回值，委托可以看作是对函数的抽象，是函数的“类”，委托的实例将代表一个具体的函数。

   这里有一点是需要注意的，也就是委托使用的前提：委托对象所搭载的所有方法必须具有相同的原形和形式，也就是拥有相同的参数列表和返回值类型。

11.抽象工厂模式：

   小菜遇到了一件麻烦事，用他的话来说：都是换数据库惹的祸。事情是这样的，小菜写好的一个原本用SQLServer作为数据库的电子商务网站，现在客户想要改成Access作为数据库。于是大量的改动来了，只有靠时间来解决问题。这时，大鸟就向小菜讲解了抽象工厂模式的使用。

   抽象工厂模式，提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。这样，就算再换成Oracle为数据库，也不用担心了，可以很快的搞定。

   抽象工厂模式最大的好处就是易于交换产品系列，它只需要改变具体工厂即可使用不同的产品配置。第二大好处便是让具体的创建实例过程与客户端分离，客户端通过抽象接口来操纵实例。

   但是如果需求来自增加功能，抽象工厂模式就暴露的它的缺点，此时会有大批量的改动。这时就可以用简单工厂来改进抽象工厂。

12.状态模式：

   不同的工作时间，会有不同的工作状态。针对一个对象之间大量的状态转换，程杰老师说明了状态模式。

   状态模式是当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。简单来说，状态模式就是主要解决控制一个对象状态转换的条件表达式过于复杂的情况。也就是，将复杂的判断简单化。

13.适配器模式：

   初到NBA的姚明必须要配一名翻译者，教练、队员与他的对话全部通过翻译来沟通。这个翻译者我们就可以理解为是适配器。

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

   那么合适使用适配器模式呢？当两个类所做的事情相同或相似，但是具有不同的接口时，我们就可以使用适配器模式。这样客户代码可以统一调用同一接口。

14.备忘录模式：

   如果再给我一次机会，我一定不会忘记存储数据！可是时间不会倒流，那么我们该如何避免再出现这种情况呢？

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

15.组合模式：

   一家大的公司又有很多子公司，针对这种整体与部分可以被一致对待的问题，可以考虑组合模式。

   组合模式，就是将对象组合成树形结构以表示“部分-整体”的层次结构。它使得用户对单个对象和组合对象的使用具有一致性。

   至于何时使用该模式？当你发现需求中体现部分与整体层次的结构时，以及你希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑这种模式了。

16.迭代器模式：

   顾名思义，迭代，就是按顺序逐一遍历。这种模式，提供一种方法，顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。

   当需要访问一个聚集对象，而且不管这些对象是什么都需要遍历的时候，就可以考虑使用迭代器模式。

 

未完待续，敬请期待~