责任链模式

责任链模式涉及到的角色如下所示：

　　●　　抽象处理者(Handler)角色：定义出一个处理请求的接口。如果需要，接口可以定义
出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者Java接口实现。上图中Handler类的聚合关系给出了具体子类对下家的引用，抽象方法handleRequest()规范了子类处理请求的操作。

　　●　　具体处理者(ConcreteHandler)角色：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。
命令模式

1.概念

　　将来自客户端的请求传入一个对象，从而使你可用不同的请求对客户进行参数化。用于“行为请求者”与“行为实现者”解耦，可实现二者之间的松耦合，以便适应变化。分离变化与不变的因素。

　　在面向对象的程序设计中，一个对象调用另一个对象，一般情况下的调用过程是：创建目标对象实例；设置调用参数；调用目标对象的方法。

但在有些情况下有必要使用一个专门的类对这种调用过程加以封装，我们把这种专门的类称作command类。

Command模式可应用于
a）整个调用过程比较繁杂，或者存在多处这种调用。这时，使用Command类对该调用加以封装，便于功能的再利用。
b）调用前后需要对调用参数进行某些处理。
c）调用前后需要进行某些额外处理，比如日志，缓存，记录历史操作等。

Command模式有如下效果：
a）将调用操作的对象和知道如何实现该操作的对象解耦。
b）Command是头等对象。他们可以像其他对象一样被操作和扩展。
c）你可将多个命令装配成一个符合命令。
d）增加新的Command很容易，因为这无需改变现有的类。
解析器模式

1.定义
给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中句子。
属于行为类模式。

2.解释器模式的使用场景

重复发生的问题可以使用解释器模式：比如根据用户输入的公式进行加减乘除四则运算，但是他们输入的公式每次都不同，有时是a+b-c*d，有时是a*b+c-d，等等等等个，公式千变万化，但是都是由加减乘除四个非终结符来连接的，这时我们就可以使用解释器模式。

一个简单语法需要解释的场景：你看看下面给出的例子，非终结表达式，文法规则越多，复杂度越高，而且类间还要进行递归调用。因此解释器模式一般用来解析比较标准的字符集，例如sql语法分析，不过该部分逐渐被专用工具所取代。
迭代器模式

迭代器模式遍历集合的成熟模式，迭代器模式的关键是将遍历集合的任务交给一个叫做迭代器的对象，它的工作时遍历并选择序列中的对象，而客户端程序员不必知道或关心该集合序列底层的结构。

　　迭代器模式的结构中包括四种角色。

　　一、集合：一个接口，规定了具体集合需要实现的操作。

　　二、具体集合：具体集合石实现了集合接口的一个实例，具体的集合按照一定的结构存储对象。具体集合应该有一个方法，该方法返回一个针对该集合的具体迭代器。

　　三、迭代器：一个接口，规定了遍历具体集合的方法，比如next()方法。

　　四、具体迭代器：实现了迭代器接口的类的实例。具体迭代器在实现迭代器接口所规定的遍历集合的方法时，比如next()方法，要保证首次调用将按着集合的数据结构找到该集合的一个对象，并且每当找到集合中的一个对象，立即根据该集合的存储结构得到待遍历的后继对象的引用，并保证一次调用next()方法可以遍历集合。
状态模式

1.介绍

用一句话来表述，状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。

2.状态模式所涉及到的角色有：

　　●　　环境(Context)角色，也成上下文：定义客户端所感兴趣的接口，并且保留一个具体状态类的实例。这个具体状态类的实例给出此环境对象的现有状态。

　　●　　抽象状态(State)角色：定义一个接口，用以封装环境（Context）对象的一个特定的状态所对应的行为。

　　●　　具体状态(ConcreteState)角色：每一个具体状态类都实现了环境（Context）的一个状态所对应的行为。
中介者模式

1.定义

定义一个中介对象来封装系列对象之间的交互。中介者使各个对象不需要显示地相互引用，从而使其耦合性松散，而且可以独立地改变他们之间的交互。

2.使用终结者模式的场合

（1）.一组定义良好的对象，现在要进行复杂的通信。

（2）.定制一个分布在多个类中的行为，而又不想生成太多的子类。

可以看出，中介对象主要是用来封装行为的，行为的参与者就是那些对象，但是通过中介者，这些对象不用相互知道。呵呵~~~

3.使用中介者模式的优点：

（1）.降低了系统对象之间的耦合性，使得对象易于独立的被复用。

（2）.提高系统的灵活性，使得系统易于扩展和维护。

4.使用中介者模式的缺点：

中介者模式的缺点是显而易见的，因为这个“中介“承担了较多的责任，所以一旦这个中介对象出现了问题，那么整个系统就会受到重大的影响。
备忘录模式

1.介绍

备忘录模式又叫做快照模式(Snapshot Pattern)或Token模式，是对象的行为模式。

　　备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捕捉(Capture)住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。备忘录模式常常与命令模式和迭代子模式一同使用。

2.

备忘录模式所涉及的角色有三个：备忘录(Memento)角色、发起人(Originator)角色、负责人(Caretaker)角色。

备忘录(Memento)角色

　　备忘录角色又如下责任：

　　（1）将发起人（Originator）对象的内战状态存储起来。备忘录可以根据发起人对象的判断来决定存储多少发起人（Originator）对象的内部状态。

　　（2）备忘录可以保护其内容不被发起人（Originator）对象之外的任何对象所读取。

　　备忘录有两个等效的接口：

　　●　　窄接口：负责人（Caretaker）对象（和其他除发起人对象之外的任何对象）看到的是备忘录的窄接口(narrow
interface)，这个窄接口只允许它把备忘录对象传给其他的对象。

　　●　　宽接口：与负责人对象看到的窄接口相反的是，发起人对象可以看到一个宽接口(wide
interface)，这个宽接口允许它读取所有的数据，以便根据这些数据恢复这个发起人对象的内部状态。

　　发起人（Originator）角色

　　发起人角色有如下责任：

　　（1）创建一个含有当前的内部状态的备忘录对象。

　　（2）使用备忘录对象存储其内部状态。

　　负责人（Caretaker）角色

　　负责人角色有如下责任：

　　（1）负责保存备忘录对象。

　　（2）不检查备忘录对象的内容。
观察者模式

1. 概述

　　有时被称作发布/订阅模式，观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。

2. 解决的问题

　　将一个系统分割成一个一些类相互协作的类有一个不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。观察者就是解决这类的耦合关系的。

3. 模式中的角色

　　3.1
抽象主题（Subject）：它把所有观察者对象的引用保存到一个聚集里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象。

　　3.2 具体主题（ConcreteSubject）：将有关状态存入具体观察者对象；在具体主题内部状态改变时，给所有登记过的观察者发出通知。

　　3.3 抽象观察者（Observer）：为所有的具体观察者定义一个接口，在得到主题通知时更新自己。

　　3.4 具体观察者（ConcreteObserver）：实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题状态协调。

4.代码实现

5. 模式总结

　　5.1 优点

　　　　5.1.1 观察者模式解除了主题和具体观察者的耦合，让耦合的双方都依赖于抽象，而不是依赖具体。从而使得各自的变化都不会影响另一边的变化。

　　5.2 缺点

　　　　5.2.1 依赖关系并未完全解除，抽象通知者依旧依赖抽象的观察者。

　　5.3 适用场景

　　　　5.3.1 当一个对象的改变需要给变其它对象时，而且它不知道具体有多少个对象有待改变时。

　　　　5.3.2
一个抽象某型有两个方面，当其中一个方面依赖于另一个方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。

6. 模式引申，应用C#中的事件委托来彻底解除通知者和观察者之间的耦合。

　　　6.1
关于委托的定义：委托是一种引用方法的类型。一旦为委托分配了方法，委托将与该方法有相同的行为。委托方法可以像其它任何方法一样，具有参数和返回值。委托可以看作是对函数（方法）的的抽象，是函数的“类”，委托的实例代表一个（或多个）具体的函数，它可以是多播的。

　　　6.2
关于事件：事件基于委托，为委托提供了一种发布/订阅机制。事件的订阅与取消与我们刚才讲的观察者模式中的订阅与取消类似，只是表现形式有所不同。在观察者模式中，订阅使用方法Attach（）来进行；在事件的订阅中使用“+=”。类似地，取消订阅在观察者模式中用Dettach（），而事件的取消用“-=”。
策略模式

1，什么是策略模式？
策略模式，又叫算法簇模式，就是定义了不同的算法族，并且之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

2，策略模式有什么好处？
策略模式的好处在于你可以动态的改变对象的行为。

3，设计原则

设计原则是把一个类中经常改变或者将来可能改变的部分提取出来，作为一个接口（c++z中可以用虚类），然后在类中包含这个对象的实例，这样类的实例在运行时就可以随意调用实现了这个接口的类的行为。下面是一个例子。

策略模式属于对象行为型模式，主要针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响
到客户端的情况下发生变化。通常，策略模式适用于当一个应用程序需要实现一种特定的服务或者功能，而且该程序有多种实现方式时使用。

4 ，策略模式中有三个对象：
（1）       环境对象：该类中实现了对抽象策略中定义的接口或者抽象类的引用。
（2）       抽象策略对象：它可由接口或抽象类来实现。
（3）       具体策略对象：它封装了实现同不功能的不同算法。

利用策略模式构建应用程序，可以根据用户配置等内容，选择不同有算法来实现应用程序的功能。具体的选择有环境对象来完成。采用这种方式可以避免由于使用条件语句而带来的代码混乱，提高应用程序的灵活性与条理性。
模板模式

1.定义

模板方法模式是类的行为模式。准备一个抽象类，将部分逻辑以具体方法以及具体构造函数的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。这就是模板方法模式的用意。

2.介绍

模板方法模式是所有模式中最为常见的几个模式之一，是基于继承的代码复用的基本技术。

　　模板方法模式需要开发抽象类和具体子类的设计师之间的协作。一个设计师负责给出一个算法的轮廓和骨架，另一些设计师则负责给出这个算法的各个逻辑步骤。代表这些具体逻辑步骤的方法称做基本方法(primitive
method)；而将这些基本方法汇总起来的方法叫做模板方法(template method)，这个设计模式的名字就是从此而来。

3.涉及到的角色

抽象模板(Abstract Template)角色有如下责任：

　　■　　定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤。

　　■　　定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。

　　具体模板(Concrete Template)角色又如下责任：

　　■　　实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤。

　　■　　每一个抽象模板角色都可以有任意多个具体模板角色与之对应，而每一个具体模板角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。
访问者模式

一、引子

　　对于系统中一个已经完成的类层次结构，我们已经给它提供了满足需求的接口。但是面对新增加的需求，我们应该怎么做呢？如果这是为数不多的几次变动，而且你不用为了一个需求的调整而将整个类层次结构统统地修改一遍，那么直接在原有类层次结构上修改也许是个不错的主意。

　　但是往往我们遇到的却是：这样的需求变动也许会不停的发生；更重要的是需求的任何变动可能都要让你将整个类层次结构修改个底朝天……。这种类似的操作分布在不同的类里面，不是一个好现象，我们要对这个结构重构一下了。

　　那么，访问者模式也许是你很好的选择。

　　二、定义与结构

　　访问者模式，顾名思义使用了这个模式后就可以在不修改已有程序结构的前提下，通过添加额外的“访问者”来完成对已有代码功能的提升。

　　《设计模式》一书对于访问者模式给出的定义为：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。从定义可以看出结构对象是使用访问者模式必须条件，而且这个结构对象必须存在遍历自身各个对象的方法。这便类似于java中的collection概念了。

　　以下是访问者模式的组成结构：

　　1)
访问者角色（Visitor）：为该对象结构中具体元素角色声明一个访问操作接口。该操作接口的名字和参数标识了发送访问请求给具体访问者的具体元素角色。这样访问者就可以通过该元素角色的特定接口直接访问它。

　　2) 具体访问者角色（Concrete Visitor）：实现每个由访问者角色（Visitor）声明的操作。

　　3) 元素角色（Element）：定义一个Accept操作，它以一个访问者为参数。

　　4) 具体元素角色（Concrete Element）：实现由元素角色提供的Accept操作。

　　5) 对象结构角色（Object
Structure）：这是使用访问者模式必备的角色。它要具备以下特征：能枚举它的元素；可以提供一个高层的接口以允许该访问者访问它的元素；可以是一个复合（组合模式）或是一个集合，如一个列表或一个无序集合。

三、举例

四、双重分派

　　对了，你在上面的例子中体会到双重分派的实现了没有？

　　首先在客户程序中将具体访问者模式作为参数传递给具体元素角色（加亮的地方所示）。这便完成了一次分派。

　　进入具体元素角色后，具体元素角色调用作为参数的具体访问者模式中的visitor方法，同时将自己（this）作为参数传递进去。具体访问者模式再根据参数的不同来选择方法来执行（加亮的地方所示）。这便完成了第二次分派。

　　五、优缺点及适用情况

　　先来看下访问者模式的使用能否避免引言中的痛苦。使用了访问者模式以后，对于原来的类层次增加新的操作，仅仅需要实现一个具体访问者角色就可以了，而不必修改整个类层次。而且这样符合“开闭原则”的要求。而且每个具体的访问者角色都对应于一个相关操作，因此如果一个操作的需求有变，那么仅仅修改一个具体访问者角色，而不用改动整个类层次。

　　看来访问者模式确实能够解决我们面临的一些问题。

　　而且由于访问者模式为我们的系统多提供了一层“访问者”，因此我们可以在访问者中添加一些对元素角色的额外操作。

　　但是“开闭原则”的遵循总是片面的。如果系统中的类层次发生了变化，会对访问者模式产生什么样的影响呢？你必须修改访问者角色和每一个具体访问者角色……

　　看来访问者角色不适合具体元素角色经常发生变化的情况。而且访问者角色要执行与元素角色相关的操作，就必须让元素角色将自己内部属性暴露出来，而在java中就意味着其它的对象也可以访问。这就破坏了元素角色的封装性。而且在访问者模式中，元素与访问者之间能够传递的信息有限，这往往也会限制访问者模式的使用。

　　《设计模式》一书中给出了访问者模式适用的情况：

　　1) 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。

　　2)
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor使得你可以将相关的操作集中起来定义在一个类中。

　　3) 当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作。

　　4)
定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。

　　你是否能很好的理解呢？

　　六、总结

　　这是一个巧妙而且复杂的模式，它的使用条件比较苛刻。当系统中存在着固定的数据结构（比如上面的类层次），而有着不同的行为，那么访问者模式也许是个不错的选择。
单例模式

1，什么是单例模式？
单例模式确保一个类只有一个实例，自行提供这个实例并向整个系统提供这个实例。

2，单例模式适合场景？
单例模式适合于一个类只有一个实例的情况，比如窗口管理器，打印缓冲池和文件系统，它们都是原型的例子。典型的情况是，那些对象的类型被遍及一个软件系统
的不同对象访问，因此需要一个全局的访问指针，这便是众所周知的单例模式的应用。当然这只有在你确信你不再需要任何多于一个的实例的情况下。
单例模式的用意在于前一段中所关心的。通过单例模式你可以：

3，单例模式特点：

确保一个类只有一个实例被建立
提供了一个对对象的全局访问指针
在不影响单例类的客户端的情况下允许将来有多个实例 。

4，应用场景举例：
我们举个比较难复制的对象：皇帝

中国的历史上很少出现两个皇帝并存的时期，是有，但不多，那我们就认为皇帝是个单例模式，在这个场景中，有皇帝，有大臣，大臣是天天要上朝参见皇帝的，今天参拜的皇帝应该是昨天、前天的一样（过渡期的不考虑，别找茬哦），大臣磕完头，抬头一看，嗨，还是昨天那个皇帝，单例模式，绝对的单例模式。
工厂模式

1.描述

工厂方法模式是类的创建模式，又叫做虚拟构造子(Virtual Constructor)模式或者多态性工厂（Polymorphic
Factory）模式。

　　工厂方法模式的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。

2.涉及角色

抽象工厂（ExportFactory）角色：担任这个角色的是工厂方法模式的核心，任何在模式中创建对象的工厂类必须实现这个接口。在实际的系统中，这个角色也常常使用抽象类实现。

　　具体工厂（ExportHtmlFactory、ExportPdfFactory）角色：担任这个角色的是实现了抽象工厂接口的具体JAVA类。具体工厂角色含有与业务密切相关的逻辑，并且受到使用者的调用以创建导出类（如：ExportStandardHtmlFile）。

　　抽象导出（ExportFile）角色：工厂方法模式所创建的对象的超类，也就是所有导出类的共同父类或共同拥有的接口。在实际的系统中，这个角色也常常使用抽象类实现。

　　具体导出（ExportStandardHtmlFile等）角色：这个角色实现了抽象导出（ExportFile）角色所声明的接口，工厂方法模式所创建的每一个对象都是某个具体导出角色的实例。

3.工厂方法模式和简单工厂模式

工厂方法模式和简单工厂模式在结构上的不同很明显。工厂方法模式的核心是一个抽象工厂类，而简单工厂模式把核心放在一个具体类上。

　　工厂方法模式退化后可以变得很像简单工厂模式。设想如果非常确定一个系统只需要一个具体工厂类，那么不妨把抽象工厂类合并到具体工厂类中去。由于只有一个具体工厂类，所以不妨将工厂方法改为静态方法，这时候就得到了简单工厂模式。

　　如果系统需要加入一个新的导出类型，那么所需要的就是向系统中加入一个这个导出类以及所对应的工厂类。没有必要修改客户端，也没有必要修改抽象工厂角色或者其他已有的具体工厂角色。对于增加新的导出类型而言，这个系统完全支持“开-闭原则”。
原型模式

1.定义

用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。

2.原型模式主要用于对象的复制，它的核心是就是类图中的原型类Prototype。Prototype类需要具备以下两个条件：

实现Cloneable接口。在java语言有一个Cloneable接口，它的作用只有一个，就是在运行时通知虚拟机可以安全地在实现了此接口的类上使用clone方法。在java虚拟机中，只有实现了这个接口的类才可以被拷贝，否则在运行时会抛出CloneNotSupportedException异常。

重写Object类中的clone方法。Java中，所有类的父类都是Object类，Object类中有一个clone方法，作用是返回对象的一个拷贝，但是其作用域protected类型的，一般的类无法调用，因此，Prototype类需要将clone方法的作用域修改为public类型。

原型模式是一种比较简单的模式，也非常容易理解，实现一个接口，重写一个方法即完成了原型模式。在实际应用中，原型模式很少单独出现。经常与其他模式混用，他的原型类Prototype也常用抽象类来替代。

3.原型模式的优点及适用场景

使用原型模式创建对象比直接new一个对象在性能上要好的多，因为Object类的clone方法是一个本地方法，它直接操作内存中的二进制流，特别是复制大对象时，性能的差别非常明显。
使用原型模式的另一个好处是简化对象的创建，使得创建对象就像我们在编辑文档时的复制粘贴一样简单。

因为以上优点，所以在需要重复地创建相似对象时可以考虑使用原型模式。比如需要在一个循环体内创建对象，假如对象创建过程比较复杂或者循环次数很多的话，使用原型模式不但可以简化创建过程，而且可以使系统的整体性能提高很多。

4.原型模式的注意事项

使用原型模式复制对象不会调用类的构造方法。因为对象的复制是通过调用Object类的clone方法来完成的，它直接在内存中复制数据，因此不会调用到类的构造方法。不但构造方法中的代码不会执行，甚至连访问权限都对原型模式无效。还记得单例模式吗？单例模式中，只要将构造方法的访问权限设置为private型，就可以实现单例。但是clone方法直接无视构造方法的权限，所以，单例模式与原型模式是冲突的，在使用时要特别注意。

深拷贝与浅拷贝。Object类的clone方法只会拷贝对象中的基本的数据类型，对于数组、容器对象、引用对象等都不会拷贝，这就是浅拷贝。如果要实现深拷贝，必须将原型模式中的数组、容器对象、引用对象等另行拷贝。
抽象工厂模式

1.定义

为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类。

2.抽象工厂模式与工厂方法模式的区别

抽象工厂模式是工厂方法模式的升级版本，他用来创建一组相关或者相互依赖的对象。他与工厂方法模式的区别就在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则是针对的多个产品等级结构。在编程中，通常一个产品结构，表现为一个接口或者抽象类，也就是说，工厂方法模式提供的所有产品都是衍生自同一个接口或抽象类，而抽象工厂模式所提供的产品则是衍生自不同的接口或抽象类。

在抽象工厂模式中，有一个产品族的概念：所谓的产品族，是指位于不同产品等级结构中功能相关联的产品组成的家族。抽象工厂模式所提供的一系列产品就组成一个产品族；而工厂方法提供的一系列产品称为一个等级结构。我们依然拿生产汽车的例子来说明他们之间的区别。

3.抽象工厂模式的优点

抽象工厂模式除了具有工厂方法模式的优点外，最主要的优点就是可以在类的内部对产品族进行约束。所谓的产品族，一般或多或少的都存在一定的关联，抽象工厂模式就可以在类内部对产品族的关联关系进行定义和描述，而不必专门引入一个新的类来进行管理。

4.抽象工厂模式的缺点

产品族的扩展将是一件十分费力的事情，假如产品族中需要增加一个新的产品，则几乎所有的工厂类都需要进行修改。所以使用抽象工厂模式时，对产品等级结构的划分是非常重要的。

5.适用场景

当需要创建的对象是一系列相互关联或相互依赖的产品族时，便可以使用抽象工厂模式。说的更明白一点，就是一个继承体系中，如果存在着多个等级结构（即存在着多个抽象类），并且分属各个等级结构中的实现类之间存在着一定的关联或者约束，就可以使用抽象工厂模式。假如各个等级结构中的实现类之间不存在关联或约束，则使用多个独立的工厂来对产品进行创建，则更合适一点。

6.总结

无论是简单工厂模式，工厂方法模式，还是抽象工厂模式，他们都属于工厂模式，在形式和特点上也是极为相似的，他们的最终目的都是为了解耦。在使用时，我们不必去在意这个模式到底工厂方法模式还是抽象工厂模式，因为他们之间的演变常常是令人琢磨不透的。经常你会发现，明明使用的工厂方法模式，当新需求来临，稍加修改，加入了一个新方法后，由于类中的产品构成了不同等级结构中的产品族，它就变成抽象工厂模式了；而对于抽象工厂模式，当减少一个方法使的提供的产品不再构成产品族之后，它就演变成了工厂方法模式。
所以，在使用工厂模式时，只需要关心降低耦合度的目的是否达到了。
构造器(Builder)模式

1.定义

将一个复杂对象的构建和表示分离，是同样的创建构建过程可以创造不同的表示。

Builder模式是一步一步创建一个复杂的对象，它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们。用用不知道内部的具体构建细节。Builder模式是非常类似抽象工厂模式，细微的区别大概只是在反复使用中才能体会到。

2.为何使用建造者模式

是为了将复杂对象的构建过程与它的部件分离。注意: 是解耦过程和部件。

因为一个复杂的对象，不但有很多大量组成部分。例如汽车，有很多部件：车轮、方向盘、发动机，还有各种小零件等等，部件很多，但远不止这些，如何将这些部件装配成一辆汽车，这个装配过程也很复杂(需要很好的组装技术)，Builder模式就是为了将部件和组装过程分开。

3.Builder模式的应用

在Java实际使用中，我们经常用到"池"(Pool)的概念，当资源提供者无法提供足够的资源，并且这些资源需要被很多用户反复共享时，就需要使用池。

"池"实际是一段内存，当池中有一些复杂的资源的"断肢"(比如数据库的连接池，也许有时一个连接会中断)，如果循环再利用这些"断肢"，将提高内存使用效率，提高池的性能。修改Builder模式中Director类使之能诊断"断肢"断在哪个部件上，再修复这个部件。
Merge branch 'devstruct'