版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wangyang1354/article/details/51868622
设计模式源代码下载
1 模板方法模式
模板方法模式定义了一个算法的步骤，并允许子类别为一个或多个步骤提供其实践方式。让子类别在不改变算法架构的情况下，重新定义算法中的某些步骤。----WIKIPEDIA个人理解
模板方法模式相对而言比较简单，一般的都是由抽象类定义好模板方法，然后，子类通过继承并实现其父类中定义好的模板中需要执行的具体的方法，调用子类对象的模板方法时，会执行该类中的具体实现的方法。这个模式我个人的感觉有点像是面向过程的操作，执行完一道工序，接着下一道工序。
"围观"设计模式(18)--行为型之模板方法模式（TemplateMethod Pattern）
2 观察者模式
观察者模式是软件设计模式的一种。在此种模式中，一个目标对象管理所有相依于它的观察者对象，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实时事件处理系统。----WIKIPEDIA个人理解
观察者模式，就是使得被观察者中持有观察者的对象实例，在发生某些事件的时候，通过notify“通知”观察者，完成相应的操作，他也叫作发布-订阅模式，定义对象间一对多的依赖关系，使得被观察者对象产生动作，即可通知其依赖的对象该被观察者发生了变更。"围观"设计模式(19)--行为型之观察者模式（Observer Pattern）
3 策略模式
策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。比如每个人都要“交个人所得税”，但是“在美国交个人所得税”和“在中国交个人所得税”就有不同的算税方法。----WIKIPEDIA个人理解
策略模式从名字就可以看出，有多种选择，不同的策略对应着不同的实现方式，那么一般的形式为一个接口采用多种实现方式（也就是提供了不同的策略），然后再提供一个策略的选择类即可，定义中：定义一组算法，将每个算法都封装起来，并且使得他们之间可以相互的转换。通过上面我提到的这种方式来看，一组算法就是指的多种的实现方式，而将每个算法都封装起来并使得他们之间可以互换，实现了统一的接口，自然可以实现互换了。
"围观"设计模式(20)--行为型之策略模式（Strategy Pattern）
4 状态模式
状态模式--允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。----百度百科个人理解
状态模式应该说可以理解为某种状态下，程序的执行流程可能会发生变化，类似于交通灯，红灯的时候停下，绿灯行走，黄灯时等一等，这就是三种状态下我们人对其作出的相应的变化。再比如，公交车应该都坐过的，公交车停车的时候，可以上车和下车；公交车行驶的时候，不允许下车和上车，那么，这里公交车停车和行驶是两种状态，这两种状态对于后续人上车下车的行为产生了一定的影响。通俗点就是说，某种状态作为先决条件时，后面的行为受到了前面的这种状态的影响，这种情况比较适合运用状态模式。
"围观"设计模式(21)--行为型之状态模式（State Pattern）
5 责任链模式
责任链模式在面向对象程式设计里是一种软件设计模式，它包含了一些命令对象和一系列的处理对象。每一个处理对象决定它能处理哪些命令对象，它也知道如何将它不能处理的命令对象传递给该链中的下一个处理对象。该模式还描述了往该处理链的末尾添加新的处理对象的方法。----WIKIPEDIA个人的理解
责任链模式用到了链表的数据结构，存在一定的次序性，A->B->C这样的一条链表，在责任链模式中，请求交给A进行处理，如果A处理不了交给B，B如果处理的了进行处理，否则交给C处理，模式的关键在于构建这样的一个链表，并且完成链表之间这些处理情况的切换，这一点在定义中应该是说可以把不能处理的命令对象传递给链中的下一个处理对象。这么看来的话，我们平时的分层结构是不是可以理解为非纯正的责任链模式呢？但是我们分层的结构中可能每一层都要完成一些自己应该做的事情，那么，这样的话并不是和责任链模式一致，因为在责任链中是将整个的‘责任’推给下一个节点，不过从某种意义上看的话是有点相似的，因为这也是我个人的理解和思考，读者有不同的意见可以评论。
"围观"设计模式(22)--行为型之职责链模式（Chain Of Responsibility Pattern）
6 命令模式
在面向对象程式设计的范畴中，命令模式是一种设计模式，它尝试以物件来代表实际行动。命令物件可以把行动(action) 及其参数封装起来，于是这些行动可以被：重复多次
取消（如果该物件有实作的话）
取消后又再重做
这些都是现代大型应用程序所必须的功能，即“复原”及“重复”。----WIKIPEDIA
个人理解
命令模式是一个高内聚的模式，它将一个请求封装为一个对象，让你使用不同的请求将客户端参数化，在项目中应用比较广泛，他的封装性比较好，将请求方和接收方分离开来，扩展性较好。命令模式中主要有三种角色，一个是命令的接受者（Receiver），他负责对于收到的命令作出响应。一个是命令（Command）角色，他负责定义接受者需要执行什么样的命令。另一个是调用者（Invoker），接收命令调用并执行命令。但是命令模式也存在不足，如果命令较多的时候那么会存在多个子类，导致臃肿，可以结合其他的模式进行设计，如结合责任链模式实现命令的解析、结合模板方法模式减少子类的膨胀问题。"围观"设计模式(23)--行为型之命令模式（Command Pattern）
7 访问者模式
访问者模式：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。个人理解
访问者模式，扩展能力很好，符合开闭原则，对于扩展开放，对修改关闭。但是从类的实现情况来看，访问者类和元素类相互之间依赖，依赖关系较强，不过可以通过抽象类或者接口的形式，将依赖关系转移到上层抽象类或者接口中，从而降低对实现类的依赖。访问者模式的出发点：业务规则要求遍历多个不同的对象。访问者模式是对于迭代器模式的扩充，他可以访问不同的对象，实现遍历的目的。
"围观"设计模式(24)--行为型之访问者模式（Visitor Pattern）
8 中介者模式
用一个对象封装一系列的对象交互，中介者使对象不需要显示的相互作用，从而使其耦合松散，而且可以独立的改变他们之间的独立。个人理解
当多个对象之间存在着过多的耦合时，可以通过中介者模式进行解耦，将具体的对象之间的耦合转为中介者与具体对象的耦合，假如说之前是三个对象的相互之间的耦合，转为中介者与具体类的耦合之后，从耦合性上大大的降低了，这样如果再来对其进行修改的话，那么变更部分主要在中介者部分，从而使得该结构更加稳定。
角色分析
中介者角色分以下几个部分：
1. Mediator抽象中介者角色：抽象中介者角色定义统一的接口，用于各同事角色之间的通信。
2. Concrete Mediator具体中介者角色：具体中介者角色通过协调各同事角色实现写作行为，依赖于各同事角色。
3. Colleague同事角色：每个同事类的任务中，包括自身需要完成的功能，以及自己完不成要交给中介者进行其余处理的部分功能。
"围观"设计模式(25)--行为型之中介者模式（Mediator Pattern）
9 备忘录模式
所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。个人理解
备忘录模式是用于将对象的状态暂存在某些特殊情况下可以将其进行恢复的模式，可以通过多种方式实现，包括clone以及一般方式以及多种参数的备忘录等形式。标准的备忘录在项目中很难直接应用进去，多数为其变形后的处理方式。
备忘录模式主要包含入下几个角色：
Originator: 原发器。负责创建一个备忘录，用以记录当前对象的内部状态，通过也可以使用它来利用备忘录恢复内部状态。同时原发器还可以根据需要决定Memento存储Originator的那些内部状态。
Memento: 备忘录。用于存储Originator的内部状态，并且可以防止Originator以外的对象访问Memento。在备忘录Memento中有两个接口，其中Caretaker只能看到备忘录中的窄接口，它只能将备忘录传递给其他对象。Originator可以看到宽接口，允许它访问返回到先前状态的所有数据。
Caretaker: 负责人。负责保存好备忘录，不能对备忘录的内容进行操作和访问，只能够将备忘录传递给其他对象。
"围观"设计模式(26)--行为型之备忘录模式（Memento Pattern）
10 解释器模式
解析器是一种按照规定的语法进行解析的例子，在现在的项目中使用较少，定义如下：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器用于解释语言中的句子。个人理解
解释器模式在项目中很少使用，因为他会引起效率、性能以及维护等问题，准备使用该模式时可以考虑开源框架如：Expression4J、MESP、Jep等。解释器模式一般用来解析比较标准的字符集，比如说SQL语法分析等。
解释器角色
解释器模式主要包含如下几个角色：
AbstractExpression: 抽象表达式。声明一个抽象的解释操作，该接口为抽象语法树中所有的节点共享。
TerminalExpression: 终结符表达式。实现与文法中的终结符相关的解释操作。实现抽象表达式中所要求的方法。文法中每一个终结符都有一个具体的终结表达式与之相对应。
NonterminalExpression: 非终结符表达式。为文法中的非终结符相关的解释操作。
Context: 环境类。包含解释器之外的一些全局信息。
Client: 客户类。
抽象语法树描述了如何构成一个复杂的句子，通过对抽象语法树的分析，可以识别出语言中的终结符和非终结符类。 在解释器模式中由于每一种终结符表达式、非终结符表达式都会有一个具体的实例与之相对应，所以系统的扩展性比较好。
"围观"设计模式(27)--行为型之解释器模式（Interpreter Pattern）