‘壹’ 设计模式（五）行为型模式
在上一篇结构型模式中，我们以功能为基本单位，研究了一些设计模式，用于实现功能转换、功能组合、功能封装等目的。
我们知道，面向对象编程有两个核心元素：对象、对象间通信协作。从面向对象的角度看，任何系统和功能，都是由一个个对象，相互分工合作实现的。推而广之，很多系统也都是这样组织和运行的。
本章的设计模式，列举了通用场景下常用功能机制的经典实现方法，讲解了经典实现中是如何高效组织对象、控制对象协作交互的，具有很好的参考价值。
示例：https://www.runoob.com/design-pattern/chain-of-responsibility-pattern.html
责任链模式，就是把程序处理对象前后排列起来，形成一条处理线。处理线上需要被处理的信息，在处理线上向下传递，任何一个节点都可以随时中断传递。
GUI系统中的事件传递机制（在Javascript中叫做事件冒泡），是责任链模式最典型的应用之一。
当某一事件发生时，最顶层GUI对象会首先收到事件，但是它先不处理，而是依次交给命中的子GUI对象处理。当子GUI对象返回为False时，表示事件未被接收，此时父GUI对象才真正对发生的事件进行业务处理。
可以看出，事件传递机制，是一种增强版的责任链模式，它的节点处理权，经历了向下和向上的双向传递过程。
总结：当项目中一个数据对象，需要被多个处理对象进行处理时，可以将处理对象链接起来，然后把数据对象传递给头节点，随着处理的进行，数据对象的处理权会在处理链中流动，从而完成整个处理过程。
责任链模式结构适用于需求固定的场景，用于实现简单高效的处理机制。假如需求不断变化，而且功能很复杂，那么用责任链模式很可能就无法胜任了，需要采用新的高复杂度的设计。例如，如果想要数据对象在所有处理对象中根据状态来实现跳转，可以选择使用状态机等其他方案来实现。
示例：https://www.runoob.com/design-pattern/command-pattern.html
想要实现撤销、重做、事务等功能，可以使用此设计模式。通常在编辑器、数据库中有此类功能需求。
命令也就是请求，或者叫调用。命令模式要求将请求参数和请求相关的方法封装在一起。
请求对象中封装了实现“撤销”、“重做”、“事务”功能所需要的所有信息，实现了关联信息的高内聚，所以可以实现我们想要的功能。
例如，可以在请求对象中保存修改之前的值、修改之后的值。利用修改之前的值，可以实现“撤销”功能；利用修改之后的值，可以实现“重做”功能。如果将所有请求对象都记录下来，并按照先后顺序排列起来，形成“撤销重做”堆栈，这样就可以实现连续的“撤销”、“重做”。“事务”则是“撤销”与“重做”的结合体，正常执行流程等同于“重做”，发生错误需要回滚，等同于“撤销”。
如果不采用这种方式，会导致实现这些功能的信息，分散在源码中多个地方，或者已经丢失，没有保存，就无法实现“撤销”、“重做”、“事务”功能。
同时，实现请求参数高内聚，也可以很方便地将它们保存到磁盘上，保存到文件的过程叫做“序列化”，从文件中读取的过程叫“反序列化”。这里的序列指的就是二进制流。
Qt中与命令模式相关的部分是：Undo Framework，里面有示例项目，不熟悉的同学可以抽点时间看一看。
示例：https://www.runoob.com/design-pattern/interpreter-pattern.html
顾名思义，解释器模式是用来实现解释器的。 解释器是这样一个程序：解释器以符合语法的文本为输入，解释输入内容，完成一定的计算功能。文本可以在程序运行时动态加载，动态解释、动态执行。
实现简单的解释器：命令行程序，如ping命令、cd命令等； 实现复杂的解释器：脚本语言解释器，如python，lua，javascript；计算器。
我们知道，在GUI图形用户界面被发明之前，人类和程序之间的交互是通过敲命令行实现的，缺点是使用难度较大，门槛较高。 在GUI发明以后，交互更加友好，电脑更加易于使用了，所以也更加普及了。
但是GUI交互的缺点在于，不够灵活，对参数的控制粒度不够细致。例如，现在大多数开发者都使用集成开发环境来开发软件，一般情况下都使用默认参数，比较方便。但是如果你想要更改某些编译选项，可能还是需要直接修改底层的编译命令。命令相对于GUI元素更加灵活，过于灵活的地方用GUI比较难于实现，例如组合、递归、跳转等等。在这些场景下，使用解释器是非常合适的。但是通常情况下，这个模式并不常用。
示例：https://www.runoob.com/design-pattern/iterator-pattern.html
在需要多次遍历同一个数据集合的时候，为了少些一些for，或者想要把遍历过程封装起来，降低耦合，就可以使用迭代器模式。这个模式非常常用。
迭代器就是一个专门用来遍历数组的类。它只需要实现两个接口：hasNext()、next()。 hasNext()接口用于控制循环何时停止；next()接口用于取出当前位置的数据元素，并将遍历指针指向下一个元素。 当然，构造迭代器对象的时候，需要将数据集合传递给迭代器，让迭代器知道要遍历哪些数据。
原本需要用for循环来遍历的代码，现在通过封装，提取出了“遍历”这一功能所需要的必要信息，定义了两个接口，把不必要暴露的信息封装在了迭代器中，妥妥的实现了解耦。
示例：https://www.runoob.com/design-pattern/mediator-pattern.html
中介者模式是指，在原本直接通信的对象之间，添加一个通信中间层，使对象间通信变为间接通信，降低对象间的耦合。
此模式和代理模式基本思想上是一致的。二者的区别是：代理模式是通过加一个中间层，来实现两个原本很难交互的功能主体，实现顺畅交互；中介者模式是为了降低对象间通信时的耦合而提出的，为的是提高代码的可维护性。
比较大的项目中会用到，一般存在于某些框架中。因为大的项目中对象繁多，通信也比较复杂，适合使用中介者模式。
在大的项目中，一般会有一个全局的通信管理器，任何对象都可以使用通信管理器提供的接口，将自己注册为某一个具有唯一ID消息的发送者和接收者。这样发送者只需要发送消息，不需要管谁来接收，不需要拥有发送者的实例指针，发出消息后，已注册的接收者都会收到消息。接收者不需要管信号是谁发的，即不需要拥有发送者的实例指针。
所以，中介者模式也可以叫“通信中介模式”。
示例：https://www.runoob.com/design-pattern/memento-pattern.html
这个模式和状态存档功能是绑定在一起的。为了在程序中实现状态存档功能，可以使用备忘录模式。
原例子中有三个类，个人觉得没有必要，这里我们简化成两个类，即备忘录模式中有两个类：状态对象类和状态对象管理类。 状态对象类是状态字段是集合，并提供了存取接口；状态对象管理类负责组织和保存状态对象。当然实际实现中可以根据需求增加类，配合使用，完成状态保存恢复。
当一个对象会影响到其他多个对象时，即当对象间存在一对多关系时，使用观察者模式。 一般应用于单向通知的场景，如GUI中鼠标事件、按键事件、窗口事件通知。使用Qt中的信号槽机制可以实现此模式。
“一”是指发生变化的那个对象，“多”是指需要获取此变化通知的对象组。其中，变化消息是单向地由“一”到“多”传递的。如果不是单向的或者对象间不是一对多的关系，更加复杂，就需要重新思考其他对象间通信模型。
如果不使用此模式，可能会导致观察者不能动态增加或删除；可能会造成发送者的业务代码和接收者的响应代码混在一起，耦合严重。
使用此模式，需要为观察者设计一个基类，并设计一个接收通知的接口，所有观察者需要实现通知接口；所有观察者指针可以保存在队列中，实现动态增删。
状态模式用于实现状态机。 如果一个程序功能中存在某些状态，在一定情况下，这些状态可以互相转换，并且在转换前后需要作出对应的操作，这种情况下使用状态机来实现就非常合适。
如果不使用状态机（状态模式），一般的实现方法是使用一连串的if-else，或者使用长长的switch-case来实现。这样做的缺点，一方面状态判断不够高效，另一方面是业务代码集中在一块，不好维护。
使用状态机，每个状态都是一个类，相关的业务代码分布到各自的状态类中，能够实现不同的状态及与状态相关的业务代码解耦。同时某个状态和下一个状态是关联好的，在状态切换时，效率更高，不需要执行长长的判断。
Qt中已实现状态机框架，The State Machine Framework，在此框架下，我们可以更加专注于业务实现，而不是状态机本身的技术细节。
示例：https://www.runoob.com/design-pattern/null-object-pattern.html
使用基类保存子类对象通常有两种做法：
第一种方法用指针是基本方法，但是指针用起来要非常小心，要考虑内存释放的问题。此时空对象就可以用空指针表示。 第二种方法用基类对象保存子类对象，这种方法使用起来相对省心，不用与指针打交道，使用者不用直接管理内存。例如Qt中的Qt XML C++ Classes类的设计就是采用这种方式设计的。这种情况下，因为不使用指针，就需要使用空对象来代替空指针。
可以仿造Qt XML中的类进行设计。一般需要提供isNull()接口，对象类型转换接口等。
策略模式和桥接模式类似，用于实现功能切换与组合。二者区别在于，策略模式专注于一个功能的不同实现方式；桥接模式专注于多个功能之间的组合。
将功能抽象成单独的类，功能切换只需要切换不同的功能子类即可，同一个功能需要实现同一个功能接口。
示例：https://www.runoob.com/design-pattern/template-pattern.html
模板模式应该是我们最熟悉的。 这里的模板就是接口类，接口类定义了使用者和功能提供者之间交互的函数列表。子类负责功能的具体实现。
示例：https://www.runoob.com/design-pattern/visitor-pattern.html
访问者模式用于将数据结构与数据操作相分离。
访问者模式和迭代器模式类似。迭代器模式一般用来遍历数组，所以没有把for封装起来。而访问者模式可以遍历一切类型的数据结构，具体的遍历过程被封装在接收者内部。同时，对每一个遍历得到的数组元素的操作，被封装在访问者内部。每一种对元素不同的操作，都需要新建一个访问者类。
接收者需要实现accept()接口，访问者需要实现visit()接口。
每种设计模式都有使用场景，都有优点和缺点。随着需求的改变，任何一种设计模式可能都将不再适用。
‘贰’ 各位，23种设计模式都在哪些场合运用到
其中创建型有：
一、Singleton，单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点
例如：随处可见，比如Servlet，sprigMVC创建时都是单例多线程的。
完美的实例是：private static Singleton instance = new Singleton();
创建线程的方式有很多种，但是很多都扛不住多线程的检验，上面是简单又实用的例子，多线程下也是安全的。
二、Abstract Factory，抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们的具体类。
三、Factory Method，工厂方法：定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method使一个类的实例化延迟到了子类。
例如：虽然简单工厂（静态工厂）没有进入23种设计模式，但是java web中的很多配置文件玩的还是它。
Spring中下面三种方式实例化bean：
1.使用类构造器实例化
<bean id="orderService" class="cn.itcast.OrderServiceBean"/>
2.使用静态工厂方法实例化
<bean id="personService" class="cn.itcast.service.OrderFactory" factory- method="createOrder"/>
public class OrderFactory {
public static OrderServiceBean createOrder(){
return new OrderServiceBean();
}
}
3.使用实例工厂方法实例化:
<bean id="personServiceFactory" class="cn.itcast.service.OrderFactory"/>
<bean id="personService" factory-bean="personServiceFactory" factory-method="createOrder"/>
public class OrderFactory {
public OrderServiceBean createOrder(){
return new OrderServiceBean();
}
}
第一种方法，IOC容易直接根据配置文件中的class属性通过反射创建一个实例，使用的是该类的默认构造方法。第二种则是调用class指定的工厂类的
工厂方法，来返回一个相应的bean实例，值得注意的是工厂类的方法是静态方法，所以不用产生工厂本身的实例。而第三种则不同，它除了配置与第二种相同
外，唯一的不同就是方法不是静态的，所以创建bean的实例对象时需要先生成工厂类的实例。实例了bean对象时，需要对其中的属性也进行赋值，这时就是经常被提及的依赖注入。
以上其实有错误：Spring很多情况下创建对象很定是反射呀，尤其是注解和DI（依赖注入），小朋友，想什么呢？肯定不是用new()来创建：
Class c = Class.forName("cn.itcast.OrderServiceBean");
Object bean = c.newInstance();
四、Builder，建造模式：将一个复杂对象的构建与他的表示相分离，使得同样的构建过程可以创建不同的表示。
五、Prototype，原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。
行为型有：
六、Iterator，迭代器模式：提供一个方法顺序访问一个聚合对象的各个元素，而又不需要暴露该对象的内部表示。
例如：jdk中的各种容器类的基础模式
七、Observer，观察者模式：定义对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知自动更新。
例如：据说是jdk使用最多的模式,好比邮件订阅或RSS订阅
八、Template Method，模板方法：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，TemplateMethod使得子类可以不改变一个算法的结构即可以重定义该算法得某些特定步骤。
九、Command，命令模式：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化，对请求排队和记录请求日志，以及支持可撤销的操作。
十、State，状态模式：允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类。
十一、Strategy，策略模式：定义一系列的算法，把他们一个个封装起来，并使他们可以互相替换，本模式使得算法可以独立于使用它们的客户。
例如：comparator 比较器的实现利用了此模式
十二、China of Responsibility，职责链模式：使多个对象都有机会处理请求，从而避免请求的送发者和接收者之间的耦合关系 。
此处强调一点就是，链接上的请求可以是一条链，可以是一个树，还可以是一个环，模式本身不约束这个，需要我们自己去实现，同时，在一个时刻，命令只允许由一个对象传给另一个对象，而不允许传给多个对象
例如：struts2 interceptor 用到的就是是责任链模式
十三、Mediator，中介者模式：用一个中介对象封装一些列的对象交互。
十四、Visitor，访问者模式：表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作。
十五、Interpreter，解释器模式：给定一个语言，定义他的文法的一个表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
十六、Memento，备忘录模式：在不破坏对象的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
结构型有：
十七、Composite，组合模式：将对象组合成树形结构以表示部分整体的关系，Composite使得用户对单个对象和组合对象的使用具有一致性。
十八、Facade，外观模式：为子系统中的一组接口提供一致的界面，facade提供了一高层接口，这个接口使得子系统更容易使用。
十九、Proxy，代理模式：为其他对象提供一种代理以控制对这个对象的访问。
例如：经典的体现在Spring AOP切面中，Spring中利用了俩种代理类型。
其实，代理也分为静态和动态，但是我们一般常用动态，因为静态代理秀不起来
二十、Adapter,适配器模式：将一类的接口转换成客户希望的另外一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作。
其中对象的适配器模式是各种结构型模式的起源，分为三种：类，对象，接口的适配器模式。
结一下三种适配器模式的应用场景：
类的适配器模式：当希望将一个类转换成满足另一个新接口的类时，可以使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口即可。
对象的适配器模式：当希望将一个对象转换成满足另一个新接口的对象时，可以创建一个Wrapper类，持有原类的一个实例，在Wrapper类的方法中，调用实例的方法就行。
接口的适配器模式：当不希望实现一个接口中所有的方法时，可以创建一个抽象类Wrapper，实现所有方法，我们写别的类的时候，继承抽象类即可。
例如：java io流中大量使用
二十一、Decrator，装饰模式：动态地给一个对象增加一些额外的职责，就增加的功能来说，Decorator模式相比生成子类更加灵活。
对比：适配器模式主要是为了接口的转换，而装饰者模式关注的是通过组合来动态的为被装饰者注入新的功能或行为(即所谓的责任)。
二十二、Bridge，桥模式：将抽象部分与它的实现部分相分离，使他们可以独立的变化。
二十三、Flyweight，享元模式：主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，通常与工厂模式一起使用。
例如：数据库连接池便是这个原理
‘叁’ 软件设计模式主要有哪几种
软件设计模式主要有以下三大类共23种：
一、创建型模式：
1、工厂方法模式工厂方法模式的创建是因为简单工厂模式有一个问题，在简单工厂模式中类的创建依赖工厂类，如果想要拓展程序，必须对工厂类进行修改，这违背了开闭原则，所以就出现了工厂方法模式，只需要创建一个工厂接口和多个工厂实现类。
2、抽象工厂模式抽象工厂模式是提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。区别于工厂方法模式的地方，工厂方法模式是创建一个工厂，可以实现多种对象；而抽象工厂模式是提供一个抽象工厂接口，里面定义多种工厂，每个工厂可以生产多种对象。
3、单例模式单例模式能保证一个类仅有一个实例，并提供一个访问它的全局访问点，同时在类内部创造单一对象，通过设置权限，使类外部无法再创造对象。单例对象能保证在一个JVM中，该对象只有一个实例存在。
4、建造者模式建造者模式是将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。在程序当中就是将一些不会变的基本组件，通过builder来进行组合，构建复杂对象，实现分离。
5、原型模式：原型模式是用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。其实就是将对象复制了一份并返还给调用者，对象需继承Cloneable并重写clone方法。原型模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。
二、结构型模式：
1、适配器模式适配器模式是使得原本由于接口不兼容而不能一起工作的那些类可以一起工作，衔接两个不兼容、独立的接口的功能，使得它们能够一起工作，适配器起到中介的作用。
2、装饰模式：装饰器模式是动态地给一个对象添加一些额外的职责，给一个对象增加一些新的功能，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。除了动态的增加，也可以动态的撤销，要做到动态的形式，不可以用继承实现，因为继承是静态的。
3、代理模式代理模式是为其他对象提供一种代理以控制对这个对象的访问，也就是创建类的代理类，间接访问被代理类的过程中，对其功能加以控制。
4、外观模式外观模式是为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
5、桥接模式桥接模式是将抽象部分与实现部分分离，使它们都可以独立的变化。桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化（突然联想到了mvc模式）。
6、组合模式：组合模式是将对象组合成树形结构以表示"部分-整体"的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。
7、享元模式：享元模式是运用共享技术有效地支持大量细粒度的对象。享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，重用现有的同类对象，若未找到匹配的对象，则创建新对象，这样可以减少对象的创建，降低系统内存，提高效率。
三、行为型模式：
1、策略模式：
策略模式是定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换，且算法的变化不会影响到使用算法的客户。
2、模版方法模式：
模板方法模式是定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。该模式就是在一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用。
模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤，将一些固定步骤、固定逻辑的方法封装成模板方法。调用模板方法即可完成那些特定的步骤。
3、观察者模式：
观察者模式是定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
也就是当被观察者状态变化时，通知所有观察者，这种依赖方式具有双向性，在QQ邮箱中的邮件订阅和RSS订阅，当用户浏览一些博客时，经常会看到RSS图标，简单来说就是当订阅了该文章，如果后续有更新，会及时通知用户。这种现象即是典型的观察者模式。
4、迭代器模式：
迭代器模式是提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。
在Java当中，将聚合类中遍历各个元素的行为分离出来，封装成迭代器，让迭代器来处理遍历的任务；使简化聚合类，同时又不暴露聚合类的内部，在我们经常使用的JDK中各个类也都是这些基本的东西。
5、责任链模式：
责任链模式是避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。
6、命令模式：
命令模式是将一个请求封装成一个对象，从而使发出者可以用不同的请求对客户进行参数化。模式当中存在调用者、接收者、命令三个对象，实现请求和执行分开；调用者选择命令发布，命令指定接收者。
7、备忘录模式：
备忘录模式是在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。创建一个备忘录类，用来存储原始类的信息；同时创建备忘录仓库类，用来存储备忘录类，主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，也就是做个备份。
8、状态模式：
状态模式是允许对象在内部状态发生改变时改变它的行为。对象具有多种状态，且每种状态具有特定的行为。
9、访问者模式：
访问者模式主要是将数据结构与数据操作分离。在被访问的类里面加一个对外提供接待访问者的接口，访问者封装了对被访问者结构的一些杂乱操作，解耦结构与算法，同时具有优秀的扩展性。通俗来讲就是一种分离对象数据结构与行为的方法。
10、中介者模式：
中介者模式是用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
11、解释器模式：
解释器模式是给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子，基本也就用在这个范围内，适用面较窄，例如：正则表达式的解释等。
(3)设计模式中访问者模式定义扩展阅读：
软件设计的概念以及意义：
软件设计模式是对软件设计经验的总结，是对软件设计中反复出现的设计问题的成功解决方案的描述。为了记录这些成功的设计经验并方便以后使用，软件设计模式通常包含 4 个基本要素：模式名称、问题、解决方案以及效果。
模式名称实际上就是一个帮助记忆的名称，是用于软件设计的技术术语，有助于设计者之间的交流。
问题描述了设计者所面临的设计场景，用于告诉设计者在什么情况下使用该模式。
解决方案描述了设计的细节，通常会给出方案的原理图示（例如 UML 的类图，序列图等，也可能是一些示意图）及相关文字说明，如果可能，还会给出一些代码实例，以便对解决方案的深入理解。
效果描述了设计方案的优势和劣势，这些效果通常面向软件的质量属性，例如，可扩展性、可复用性等。
软件设计模式的重要意义在于设计复用。设计模式可以使设计者更加方便地借鉴或直接使用已经过证实的成功设计方案，而不必花费时间进行重复设计。一些设计模式甚至提供了显示的类图设计及代码实例，为设计的文档化及软件的开发提供了直接的支持。
‘肆’ 设计模式有哪些
总体来说设计模式分为三大类：一、创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。二、结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。三、行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。1、工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。工厂模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，这就用到工厂方法模式。创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。2、抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。抽象工厂需要创建一些列产品，着重点在于＂创建哪些＂产品上，也就是说，如果你开发，你的主要任务是划分不同差异的产品线，并且尽量保持每条产品线接口一致，从而可以从同一个抽象工厂继承。3、单例模式：单例对象（Singleton）是一种常用的设计模式。在Java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。
‘伍’ 设计模式的设计原则
为什么要提倡“Design Pattern呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？面向对象有几个原则：单一职责原则 （Single Responsiblity Principle SRP）开闭原则（Open Closed Principle，OCP）、里氏代换原则（Liskov Substitution Principle，LSP）、依赖倒转原则（Dependency Inversion Principle，DIP）、接口隔离原则（Interface Segregation Principle，ISP）、合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）、最小知识原则（Principle of Least Knowledge，PLK，也叫迪米特法则）。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他几条，则可以看做是开闭原则的实现方法。
设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。 此原则是由Bertrand Meyer提出的。原文是：“Software entities should be open for extension,but closed for modification”。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原（是“原”，指原来的代码）代码的情况下进行扩展。那么怎么扩展呢？我们看工厂模式“factory pattern”：假设中关村有一个卖盗版盘和毛片的小子，我们给他设计一“光盘销售管理软件”。我们应该先设计一“光盘”接口。如图：
[pre]
______________
|<>|
| 光盘 |
|_____________|
|+卖() |
| |
|_____________|
[/pre]
而盗版盘和毛片是其子类。小子通过“DiscFactory”来管理这些光盘。代码为： publicclassDiscFactory{publicstatic光盘getDisc(Stringname){return(光盘)Class.forName(name).newInstance();}}有人要买盗版盘，怎么实现呢？ publicclass小子{publicstaticvoidmain(String[]args){光盘d=DiscFactory.getDisc(盗版盘);d.卖();}}如果有一天，这小子良心发现了，开始卖正版软件。没关系，我们只要再创建一个“光盘”的子类“正版软件”就可以了，不需要修改原结构和代码。怎么样？对扩展开放，对修改关闭——“开闭原则”。
工厂模式是对具体产品进行扩展，有的项目可能需要更多的扩展性，要对这个“工厂”也进行扩展，那就成了“抽象工厂模式”。 合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）经常又叫做合成复用原则。合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是：要尽量使用合成/聚合，尽量不要使用继承。
就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。“牵一发而动全身”！面向对象是要把波动限制在尽量小的范围。
在Java中，应尽量针对Interface编程，而非实现类。这样，更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系，“不要与陌生人说话”。这样，城门失火，才不至于殃及池鱼。扩展性和维护性才能提高。 设计模式分为三种类型，共23种。 创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。 行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)、访问者模式。 按字典序排列简介如下。
Abstract Factory（抽象工厂模式）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
Adapter（适配器模式）：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
Bridge（桥接模式）：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
Builder（建造者模式）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
Chain of Responsibility（责任链模式）：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
Command（命令模式）：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
Composite（组合模式）：将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
Decorator（装饰模式）：动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
Facade（外观模式）：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
Factory Method（工厂模式）：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。
Flyweight（享元模式）：运用共享技术有效地支持大量细粒度的对象。
Interpreter（解析器模式）：给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。
Iterator（迭代器模式）：提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。
Mediator（中介模式）：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
Memento（备忘录模式）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
Observer（观察者模式）：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
Prototype（原型模式）：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
Proxy（代理模式）：为其他对象提供一个代理以控制对这个对象的访问。
Singleton（单例模式）：保证一个类仅有一个实例，并提供一个访问它的全局访问点。 单例模式是最简单的设计模式之一，但是对于Java的开发者来说，它却有很多缺陷。在九月的专栏中，David Geary探讨了单例模式以及在面对多线程（multi-threading）、类装载器（class loaders）和序列化（serialization）时如何处理这些缺陷。
State（状态模式）：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
Strategy（策略模式）：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
Template Method（模板方法模式）：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
Visitor（访问者模式）：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
从下一节开始，详细描述以下每一种设计模式。 意图
定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。
适用性 当一个类不知道它所必须创建的对象的类的时候。 当一个类希望由它的子类来指定它所创建的对象的时候。 当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。 意图
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
适用性 一个系统要独立于它的产品的创建、组合和表示时。 一个系统要由多个产品系列中的一个来配置时。 当你要强调一系列相关的产品对象的设计以便进行联合使用时。 当你提供一个产品类库，而只想显示它们的接口而不是实现时。 意图
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
适用性 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。 当构造过程必须允许被构造的对象有不同的表示时。 意图
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
适用性 当要实例化的类是在运行时刻指定时，例如，通过动态装载；或者 为了避免创建一个与产品类层次平行的工厂类层次时；或者 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。 意图
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
适用性 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。 当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。 意图
将一个类的接口转换成另外一个客户希望的接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
适用性 你想使用一个已经存在的类，而它的接口不符合你的需求。 你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作。 （仅适用于对象Adapter）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。 意图
将抽象部分与它的实现部分分离，使它们都可以独立地变化。
适用性 你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为，在程序运行时刻实现部分应可以被选择或者切换。 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时B r i d g e 模式使你可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。 对一个抽象的实现部分的修改应对客户不产生影响，即客户的代码不必重新编译。 （C++）你想对客户完全隐藏抽象的实现部分。在C++中，类的表示在类接口中是可见的。 有许多类要生成。这样一种类层次结构说明你必须将一个对象分解成两个部分。Rumbaugh称这种类层次结构为“嵌套的普化”（nested generalizations ）。 你想在多个对象间共享实现（可能使用引用计数），但同时要求客户并不知道这一点。一个简单的例子便是Coplien的String类，在这个类中多个对象可以共享同一个字符串表示（StringRep）。 意图
将对象组合成树形结构以表示“部分-整体”的层次结构。C o m p o s i t e 使得用户对单个对象和组合对象的使用具有一致性。
适用性 你想表示对象的部分—整体层次结构。 你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。 意图
动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
适用性 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。 处理那些可以撤消的职责。 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。 意图
为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
适用性 当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。 客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。 当你需要构建一个层次结构的子系统时，使用门面模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。 意图
运用共享技术有效地支持大量细粒度的对象。
适用性 一个应用程序使用了大量的对象。 完全由于使用大量的对象，造成很大的存储开销。 对象的大多数状态都可变为外部状态。 如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象。 应用程序不依赖于对象标识。由于Flyweight对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值。 意图
为其他对象提供一种代理以控制对这个对象的访问。
适用性
在需要用比较通用和复杂的对象指针代替简单的指针的时候，使用Proxy模式。下面是一 些可以使用Proxy模式常见情况： 远程代理（Remote Proxy）为一个对象在不同的地址空间提供局部代表。 虚代理（Virtual Proxy）根据需要创建开销很大的对象。 保护代理（Protection Proxy）控制对原始对象的访问。保护代理用于对象应该有不同 的访问权限的时候。 智能指引（Smart Reference）取代了简单的指针，它在访问对象时执行一些附加操作。 它的典型用途包括： 对指向实际对象的引用计数，这样当该对象没有引用时，可以自动释放它（也称为SmartPointers）。 当第一次引用一个持久对象时，将它装入内存。 在访问一个实际对象前，检查是否已经锁定了它，以确保其他对象不能改变它。 意图
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
适用性 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 可处理一个请求的对象集合应被动态指定。 意图
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作
适用性 像上面讨论的MenuItem对象那样，抽象出待执行的动作以参数化某对象。你可用过程语言中的回调（callback）函数表达这种参数化机制。所谓回调函数是指函数先在某处注册，而它将在稍后某个需要的时候被调用。Command模式是回调机制的一个面向对象的替代品。 在不同的时刻指定、排列和执行请求。一个Command对象可以有一个与初始请求无关的生存期。如果一个请求的接收者可用一种与地址空间无关的方式表达，那么就可将负责该请求的命令对象传送给另一个不同的进程并在那儿实现该请求。 支持取消操作。Command的Execute操作可在实施操作前将状态存储起来，在取消操作时这个状态用来消除该操作的影响。Command接口必须添加一个Execute操作，该操作取消上一次Execute调用的效果。执行的命令被存储在一个历史列表中。可通过向后和向前遍历这一列表并分别调用Unexecute和Execute来实现重数不限的“取消”和“重做”。 支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。在Command接口中添加装载操作和存储操作，可以用来保持变动的一个一致的修改日志。从崩溃中恢复的过程包括从磁盘中重新读入记录下来的命令并用Execute操作重新执行它们。 用构建在原语操作上的高层操作构造一个系统。这样一种结构在支持事务（Transaction）的信息系统中很常见。一个事务封装了对数据的一组变动。Command模式提供了对事务进行建模的方法。Command有一个公共的接口，使得你可以用同一种方式调用所有的事务。同时使用该模式也易于添加新事务以扩展系统。 意图
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
适用性 当有一个语言需要解释执行, 并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好： 该文法简单对于复杂的文法, 文法的类层次变得庞大而无法管理。此时语法分析程序生成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式, 这样可以节省空间而且还可能节省时间。 效率不是一个关键问题最高效的解释器通常不是通过直接解释语法分析树实现的, 而是首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。 意图
提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
适用性 访问一个聚合对象的内容而无需暴露它的内部表示。 支持对聚合对象的多种遍历。 为遍历不同的聚合结构提供一个统一的接口（即, 支持多态迭代）。 意图
用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
适用性 一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。 一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。 想定制一个分布在多个类中的行为，而又不想生成太多的子类。 意图
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
适用性 必须保存一个对象在某一个时刻的(部分)状态, 这样以后需要时它才能恢复到先前的状态。 如果一个用接口来让其它对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。 意图
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
适用性 当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。 当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。 当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之，你不希望这些对象是紧密耦合的。 意图
允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
适用性 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。 一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常, 有多个操作包含这一相同的条件结构。State模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。 意图
定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
适用性 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。 需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时，可以使用策略模式。 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。 一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。 意图
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Te m p l a t e M e t h o d 使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
适用性 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。 各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。这是Opdyke和Johnson所描述过的“重分解以一般化”的一个很好的例子。首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。 控制子类扩展。模板方法只在特定点调用“hook”操作，这样就只允许在这些点进行扩展。 意图
表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
适用性 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor使得你可以将相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作。 定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。
‘陆’ java常用的的设计模式和开发模式都有哪些
设计模式主要分三个类型、创建型、结构型和行为型。设计模式分：3种类型及23种模式。
JAVA中的开发模式：MVC是一个很常用的程序开发设计模式，M-Model（模型）：封装应用程序的状态；V-View（视图）：表示用户界面；C-Controller（控制器）：对用户的输入作出反应，创建并设置模型。
(6)设计模式中访问者模式定义扩展阅读
创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。
结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)、访问者模式。
‘柒’ 软件设计模式主要有哪几种
软件设计模式主要有以下三大类共23种：
一、创建型模式：
1、工厂方法模式
工厂方法模式的创建是因为简单工厂模式有一个问题，在简单工厂模式中类的创建依赖工厂类，如果想要拓展程序，必须对工厂类进行修改，这违背了开闭原则，所以就出现了工厂方法模式，只需要创建一个工厂接口和多个工厂实现类。
子类可以自己决定实例化哪一个工厂类，client类针对抽象接口进行编程，如果需要增加新的功能，继承工厂接口，直接增加新的工厂类就可以了，创建过程延迟到子类中进行，不需要修改之前的代码，满足了开闭原则，达到灵活地生产多种对象。
2、抽象工厂模式
抽象工厂模式是提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。区别于工厂方法模式的地方，工厂方法模式是创建一个工厂，可以实现多种对象；而抽象工厂模式是提供一个抽象工厂接口，里面定义多种工厂，每个工厂可以生产多种对象。
前者的重点在于"怎么生产"，后者的重点在于"生产哪些"；前者是一个抽象产品类，可以派生出多个具体产品类，后者是多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。
3、单例模式
单例模式能保证一个类仅有一个实例，并提供一个访问它的全局访问点，同时在类内部创造单一对象，通过设置权限，使类外部无法再创造对象。单例对象能保证在一个JVM中，该对象只有一个实例存在。
在创建的时候，省去了new操作符，降低了系统内存的使用频率，减轻了系统的压力。同时单例模式保证在一个jvm中仅存在一个实例的好处就在于好比一个军队当中只会存在一个最高级别的军官来指挥整个军队，这样才能保证独立控制整个过程，否则如果出现多个，肯定会杂乱无序。
4、建造者模式
建造者模式是将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。在程序当中就是将一些不会变的基本组件，通过builder来进行组合，构建复杂对象，实现分离。
这样做的好处就在于客户端不必知道产品内部组成的细节；同时具体的建造者类之间是相互独立的，对系统的扩展非常有利，满足开闭原则；由于具体的建造者类是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。
5、原型模式
原型模式是用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。其实就是将对象复制了一份并返还给调用者，对象需继承Cloneable并重写clone()方法。原型模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。
分为浅复制和深复制，前者是将一个对象复制后，基本数据类型的变量都会重新创建，而引用类型，指向的还是原对象所指向的；后者是将一个对象复制后，不论是基本数据类型还有引用类型，都是重新创建的。
二、结构型模式：
1、适配器模式
适配器模式是使得原本由于接口不兼容而不能一起工作的那些类可以一起工作，衔接两个不兼容、独立的接口的功能，使得它们能够一起工作，适配器起到中介的作用。
2、装饰模式
装饰器模式是动态地给一个对象添加一些额外的职责，给一个对象增加一些新的功能，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。除了动态的增加，也可以动态的撤销，要做到动态的形式，不可以用继承实现，因为继承是静态的。
3、代理模式
代理模式是为其他对象提供一种代理以控制对这个对象的访问，也就是创建类的代理类，间接访问被代理类的过程中，对其功能加以控制。
它和装饰器模式的区别在于，装饰器模式为了增强功能，而代理模式是为了加以控制。代理模式就是多一个代理类出来，替原对象进行一些操作，例如买火车票不一定在火车站买，也可以去代售点。再比如打官司需要请律师，因为律师在法律方面有专长，可以替我们进行操作。
4、外观模式
外观模式是为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
在客户端和复杂系统之间再加一层，提供一个容易使用的外观层。外观模式是为了解决类与类之家的依赖关系的，外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，比如搜狐门户网站，就利用了外观模式。
5、桥接模式
桥接模式是将抽象部分与实现部分分离，使它们都可以独立的变化。桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化（突然联想到了mvc模式）。
将抽象化与实现化解耦，使得二者可以独立变化，就好比现在常说的mvc模式，view和model之间通过control来控制，达到高内聚低耦合来解耦的目的。
6、组合模式
组合模式是将对象组合成树形结构以表示"部分-整体"的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。
创建了一个包含自己对象组的类，并提供修改对象组的方法。在系统的文件和文件夹的问题上就使用了组合模式，文件下不可以有对象，而文件夹下可以有文件对象或者文件夹对象。
7、享元模式
享元模式是运用共享技术有效地支持大量细粒度的对象。享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，重用现有的同类对象，若未找到匹配的对象，则创建新对象，这样可以减少对象的创建，降低系统内存，提高效率。
三、行为型模式：
1、策略模式
策略模式是定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换，且算法的变化不会影响到使用算法的客户。
为了统一接口下的一系列算法类（也就是多种策略），用一个类将其封装起来，使这些策略可动态切换。策略模式属于行为型模式，是为了使这些策略可以相互切换，是为了选择不同的行为。
2、模版方法模式
模板方法模式是定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。该模式就是在一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用。
模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤，将一些固定步骤、固定逻辑的方法封装成模板方法。调用模板方法即可完成那些特定的步骤。
3、观察者模式
观察者模式是定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
也就是当被观察者状态变化时，通知所有观察者，这种依赖方式具有双向性，在QQ邮箱中的邮件订阅和RSS订阅，当用户浏览一些博客时，经常会看到RSS图标，简单来说就是当订阅了该文章，如果后续有更新，会及时通知用户。这种现象即是典型的观察者模式。
4、迭代器模式
迭代器模式是提供一种方法顺序访问一个聚合对象中各个元素,而又无须暴露该对象的内部表示。
在Java当中，将聚合类中遍历各个元素的行为分离出来，封装成迭代器，让迭代器来处理遍历的任务；使简化聚合类，同时又不暴露聚合类的内部，在我们经常使用的JDK中各个类也都是这些基本的东西。
5、责任链模式
责任链模式是避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。
但是发出者并不清楚到底最终那个对象会处理该请求。在生活中学生进行请假的过程中，会涉及到，学生请假会一级一级往上批，最终处理，具体由谁批准可能不清楚。在程序当中，现在使用的struts拦截器即用到了责任链模式。
6、命令模式
命令模式是将一个请求封装成一个对象，从而使发出者可以用不同的请求对客户进行参数化。模式当中存在调用者、接收者、命令三个对象，实现请求和执行分开；调用者选择命令发布，命令指定接收者。
7、备忘录模式
备忘录模式是在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。创建一个备忘录类，用来存储原始类的信息；同时创建备忘录仓库类，用来存储备忘录类，主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，也就是做个备份。
在系统当中使用的撤销操作，即是使用了备忘录模式，系统可以保存有限次数的文件状态，用户可以进行上几个状态的恢复，也就是用到了备忘录模式。
8、状态模式
状态模式是允许对象在内部状态发生改变时改变它的行为。对象具有多种状态，且每种状态具有特定的行为。
在网站的积分系统中，用户具有不同的积分，也就对应了不同的状态；还有QQ的用户状态有几种状态，在线、隐身、忙碌等，每个状态对应不同的操作，而且你的好友也能看到你的状态。
9、访问者模式
访问者模式主要是将数据结构与数据操作分离。在被访问的类里面加一个对外提供接待访问者的接口，访问者封装了对被访问者结构的一些杂乱操作，解耦结构与算法，同时具有优秀的扩展性。通俗来讲就是一种分离对象数据结构与行为的方法。
通过这种分离，可达到为一个被访问者动态添加新的操作而无需做其它的修改的效果。访问者模式的优点是增加操作很容易，因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中，其改变不影响系统数据结构。
10、中介者模式
中介者模式是用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
例如，MVC模式中control就是model和view的中介者。与适配器区别在于，适配器是为了兼容不同的接口，而中介者是为了将显示和操作分离。
11、解释器模式
解释器模式是给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子，基本也就用在这个范围内，适用面较窄，例如：正则表达式的解释等。
参考资料来源：网络-软件设计模式
‘捌’ 设计模式都有哪些
总体来说设计模式分为三大类：
一、创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
二、结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
三、行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
1、工厂方法模式：
定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。
工厂模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，这就用到工厂方法模式。
创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。
2、抽象工厂模式：
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。抽象工厂需要创建一些列产品，着重点在于"创建哪些"产品上，也就是说，如果你开发，你的主要任务是划分不同差异的产品线，并且尽量保持每条产品线接口一致，从而可以从同一个抽象工厂继承。
3、单例模式：
单例对象（Singleton）是一种常用的设计模式。在Java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。这样的模式有几个好处：
（1）某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。
（2）省去了new操作符，降低了系统内存的使用频率，减轻GC压力。
（3）有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。
4、建造者模式：
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
5、原型模式：
原型模式虽然是创建型的模式，但是与工程模式没有关系，从名字即可看出，该模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。本小结会通过对象的复制，进行讲解。在Java中，复制对象是通过clone()实现的，先创建一个原型类。
6、适配器模式：
适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。
7、装饰器模式：
顾名思义，装饰模式就是给一个对象增加一些新的功能，而且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。
8、代理模式：
代理模式就是多一个代理类出来，替原对象进行一些操作，比如我们在租房子的时候回去找中介，为什么呢？因为你对该地区房屋的信息掌握的不够全面，希望找一个更熟悉的人去帮你做，此处的代理就是这个意思。
9、外观模式：
外观模式是为了解决类与类之家的依赖关系的，像spring一样，可以将类和类之间的关系配置到配置文件中，而外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，该模式中没有涉及到接口。
10、桥接模式：
桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化。桥接的用意是：将抽象化与实现化解耦，使得二者可以独立变化，像我们常用的JDBC桥DriverManager一样。
JDBC进行连接数据库的时候，在各个数据库之间进行切换，基本不需要动太多的代码，甚至丝毫不用动，原因就是JDBC提供统一接口，每个数据库提供各自的实现，用一个叫做数据库驱动的程序来桥接就行了。
11、组合模式：
组合模式有时又叫部分-整体模式在处理类似树形结构的问题时比较方便。使用场景：将多个对象组合在一起进行操作，常用于表示树形结构中，例如二叉树，数等。
12、享元模式：
享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，通常与工厂模式一起使用。
13、策略模式：
策略模式定义了一系列算法，并将每个算法封装起来，使其可以相互替换，且算法的变化不会影响到使用算法的客户。需要设计一个接口，为一系列实现类提供统一的方法，多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数。
14、模板方法模式：
一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用。
15、观察者模式：
观察者模式很好理解，类似于邮件订阅和RSS订阅，当我们浏览一些博客或wiki时，经常会看到RSS图标，就这的意思是，当你订阅了该文章，如果后续有更新，会及时通知你。
其实，简单来讲就一句话：当一个对象变化时，其它依赖该对象的对象都会收到通知，并且随着变化！对象之间是一种一对多的关系。
16、迭代子模式：
顾名思义，迭代器模式就是顺序访问聚集中的对象，一般来说，集合中非常常见，如果对集合类比较熟悉的话，理解本模式会十分轻松。这句话包含两层意思：一是需要遍历的对象，即聚集对象，二是迭代器对象，用于对聚集对象进行遍历访问。
17、责任链模式：
责任链模式，有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。但是发出者并不清楚到底最终那个对象会处理该请求，所以，责任链模式可以实现，在隐瞒客户端的情况下，对系统进行动态的调整。
18、命令模式：
命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开。
19、备忘录模式：
主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，个人觉得叫备份模式更形象些，通俗的讲下：假设有原始类A，A中有各种属性，A可以决定需要备份的属性，备忘录类B是用来存储A的一些内部状态，类C呢，就是一个用来存储备忘录的，且只能存储，不能修改等操作。
20、状态模式：
状态模式在日常开发中用的挺多的，尤其是做网站的时候，我们有时希望根据对象的某一属性，区别开他们的一些功能，比如说简单的权限控制等。
21、访问者模式：
访问者模式把数据结构和作用于结构上的操作解耦合，使得操作集合可相对自由地演化。访问者模式适用于数据结构相对稳定算法又易变化的系统。因为访问者模式使得算法操作增加变得容易。
若系统数据结构对象易于变化，经常有新的数据对象增加进来，则不适合使用访问者模式。访问者模式的优点是增加操作很容易，因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中，其改变不影响系统数据结构。其缺点就是增加新的数据结构很困难。
22、中介者模式：
中介者模式也是用来降低类类之间的耦合的，因为如果类类之间有依赖关系的话，不利于功能的拓展和维护，因为只要修改一个对象，其它关联的对象都得进行修改。
如果使用中介者模式，只需关心和Mediator类的关系，具体类类之间的关系及调度交给Mediator就行，这有点像spring容器的作用。
23、解释器模式：
解释器模式一般主要应用在OOP开发中的编译器的开发中，所以适用面比较窄。
(8)设计模式中访问者模式定义扩展阅读：
介绍三本关于设计模式的书：
1、《设计模式：可复用面向对象软件的基础》
作者：[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
出版社： 机械工业出版社
2、《软件秘笈：设计模式那点事》
作者：郑阿奇
出版社：电子工业出版社
3、《设计模式：基于C#的工程化实现及扩展》
作者：王翔
出版社：电子工业出版社
‘玖’ 24种设计模式
一、创建型模式
1、抽象工厂模式(Abstract factory pattern): 提供一个接口, 用于创建相关或依赖对象的家族, 而不需要指定具体类.
2、生成器模式(Builder pattern): 使用生成器模式封装一个产品的构造过程, 并允许按步骤构造. 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示.
3、工厂模式(factory method pattern): 定义了一个创建对象的接口, 但由子类决定要实例化的类是哪一个. 工厂方法让类把实例化推迟到子类.
4、原型模式(prototype pattern): 当创建给定类的实例过程很昂贵或很复杂时, 就使用原形模式.
5、单例了模式(Singleton pattern): 确保一个类只有一个实例, 并提供全局访问点.
6、多例模式(Multition pattern): 在一个解决方案中结合两个或多个模式, 以解决一般或重复发生的问题.
二、结构型模式
1、适配器模式(Adapter pattern): 将一个类的接口, 转换成客户期望的另一个接口. 适配器让原本接口不兼容的类可以合作无间. 对象适配器使用组合, 类适配器使用多重继承.
2、桥接模式(Bridge pattern): 使用桥接模式通过将实现和抽象放在两个不同的类层次中而使它们可以独立改变.
3、组合模式(composite pattern): 允许你将对象组合成树形结构来表现”整体/部分”层次结构. 组合能让客户以一致的方式处理个别对象以及对象组合.
4、装饰者模式(decorator pattern): 动态地将责任附加到对象上, 若要扩展功能, 装饰者提供了比继承更有弹性的替代方案.
5、外观模式(facade pattern): 提供了一个统一的接口, 用来访问子系统中的一群接口. 外观定义了一个高层接口, 让子系统更容易使用.
6、亨元模式(Flyweight Pattern): 如想让某个类的一个实例能用来提供许多”虚拟实例”, 就使用蝇量模式.
7、代理模式(Proxy pattern): 为另一个对象提供一个替身或占位符以控制对这个对象的访问.
三、行为型模式
1、责任链模式(Chain of responsibility pattern): 通过责任链模式, 你可以为某个请求创建一个对象链. 每个对象依序检查此请求并对其进行处理或者将它传给链中的下一个对象.
2、命令模式(Command pattern): 将”请求”封闭成对象, 以便使用不同的请求,队列或者日志来参数化其他对象. 命令模式也支持可撤销的操作.
3、解释器模式(Interpreter pattern): 使用解释器模式为语言创建解释器.
4、迭代器模式(iterator pattern): 提供一种方法顺序访问一个聚合对象中的各个元素, 而又不暴露其内部的表示.
5、中介者模式(Mediator pattern) : 使用中介者模式来集中相关对象之间复杂的沟通和控制方式.
6、备忘录模式(Memento pattern): 当你需要让对象返回之前的状态时(例如, 你的用户请求”撤销”), 你使用备忘录模式.
7、观察者模式(observer pattern): 在对象之间定义一对多的依赖, 这样一来, 当一个对象改变状态, 依赖它的对象都会收到通知, 并自动更新.
8、状态模式(State pattern): 允许对象在内部状态改变时改变它的行为, 对象看起来好象改了它的类.
9、策略模式(strategy pattern): 定义了算法族, 分别封闭起来, 让它们之间可以互相替换, 此模式让算法的变化独立于使用算法的客户.
10、模板方法模式(Template pattern): 在一个方法中定义一个算法的骨架, 而将一些步骤延迟到子类中. 模板方法使得子类可以在不改变算法结构的情况下, 重新定义算法中的某些步骤.
11、访问者模式(visitor pattern): 当你想要为一个对象的组合增加新的能力, 且封装并不重要时, 就使用访问者模式.
‘拾’ Java中23种设计模式,哪些是必须了解的
一共23种设计模式！
引用《软件秘笈-设计模式那点事》书籍：
按照目的来分，设计模式可以分为创建型模式、结构型模式和行为型模式。
创建型模式用来处理对象的创建过程；结构型模式用来处理类或者对象的组合；行为型模式用来对类或对象怎样交互和怎样分配职责进行描述。
创建型模式用来处理对象的创建过程，主要包含以下5种设计模式：
工厂方法模式（Factory Method Pattern）
抽象工厂模式（Abstract Factory Pattern）
建造者模式（Builder Pattern）
原型模式（Prototype Pattern）
单例模式（Singleton Pattern）
结构型模式用来处理类或者对象的组合，主要包含以下7种设计模式：
适配器模式（Adapter Pattern）
桥接模式（Bridge Pattern）
组合模式（Composite Pattern）
装饰者模式（Decorator Pattern）
外观模式（Facade Pattern）
享元模式（Flyweight Pattern）
代理模式（Proxy Pattern）
行为型模式用来对类或对象怎样交互和怎样分配职责进行描述，主要包含以下11种设计模式：
责任链模式（Chain of Responsibility Pattern）
命令模式（Command Pattern）
解释器模式（Interpreter Pattern）
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
备忘录模式（Memento Pattern）
观察者模式（Observer Pattern）
状态模式（State Pattern）
策略模式（Strategy Pattern）
模板方法模式（Template Method Pattern）
访问者模式（Visitor Pattern）