模板方法模式（Template）
模板方法模式： 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
■ AbstractClass：抽象类。用来定义算法骨架和原语操作，具体的子类通过重定义这些原语操作来实现一个算法的各个步骤。在这个类里面，还可以提供算法中通用的实现。
■ ConcreteClass：具体实现类。用来实现算法骨架中的某些步骤，完成与特定子类相关的功能。
模板方法模式是在实际的工作中使用比较多的一种设计模式。它体现了在程序设计中的一个很重要的思考点，那就是“变与不变”，也就是分析程序中哪些功能是可变的，哪些功能是不变的，然后把不变的部分抽象出来，进行公共的实现，把变化的部分分离出去，用接口来封装隔离，或者是用抽象类来约束子类行为。
责任链模式（Chain of Responsibility）
责任链模式： 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
职责链模式的结构如下图所示
■ Handler：定义职责的接口，通常在这里定义处理请求的方法，可以在这里实现后继链。
■ ConcreteHandler：实现职责的类，在这个类中，实现对在它职责范围内请求的处理，如果不处理，就继续转发请求给后继者。
■ Client：职责链的客户端，向链上的具体处理对象提交请求，让职责链负责处理。
职责链模式主要用来处理“客户端发出一个请求，有多个对象都有机会来处理这一个请求，但是客户端不知道究竟谁会来处理他的请求”这样的情况。也就是需要让请求者和接收者解耦，这样就可以动态地切换和组合接收者了。
职责链模式的本质：分离职责，动态组合。
在前端开发过程中，使用过gulp的同学应该很好理解责任链，因为gulp本身的文件处理机制便是基于责任链模式设计，使用链式调用，不同的loader负责对文件做不同的处理工作。实际webpack也是基于这种模式进行处理的，只是将调用和实例化的过程省略，只保留了loader和plugin的配置。
订阅者模式
命令模式（Command）
命令模式： 命令模式（Command Pattern）是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。
命令模式的关键之处就是把请求封装成为对象，也就是命令对象，并定义了统一的执行操作的接口，这个命令对象可以被存储、转发、记录、处理、撤销等，整个命令模式都是围绕这个对象在进行。
命令模式是将行为请求者和行为实现者解耦合的方式。对命令进行封装，将命令和执行命令分隔开。请求的一方发出命令，要求执行某些操作，接受一方收到命令，执行这些操作的真正实现。
■ Command：定义命令的接口，声明执行的方法。
■ ConcreteCommand：命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
■ Receiver：接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
■ Invoker：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
■ Client：创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。
命令模式的本质：封装请求。 命令模式的关键就是把请求封装成为命令对象，然后就可以对这个对象进行一系列的处理了，比如上面讲到的参数化配置、可撤销操作、宏命令、队列请求、日志请求等功能处理。
java设计模式之命令模式 - 知乎 (zhihu.com)
迭代器模式（Iterator）
迭代器模式： 提供一种方法顺序访问一个聚合对象中的各个元素，而又不需暴露该对象的内部表示。所谓聚合是指一组对象的组合结构，比如：Java中的集合、数组等。
■ Iterator：迭代器接口。定义访问和遍历元素的接口。
■ ConcreteIterator：具体的迭代器实现对象。实现对聚合对象的遍历，并跟踪遍历时的当前位置。
■ Aggregate：聚合对象。定义创建相应迭代器对象的接口。
■ ConcreteAggregate：具体聚合对象。实现创建相应的迭代器对象。
迭代器模式的功能主要在于提供对聚合对象的迭代访问。
迭代器模式的本质：控制访问聚合对象中的元素。 迭代器能实现“无须暴露聚合对象的内部实现，就能够访问到聚合对象中的各个元素”的功能，看起来其本质应该是“透明访问聚合对象中的元素”。
策略模式（Strategy）
策略模式： 定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
■ Strategy：策略接口，用来约束一系列具体的策略算法。Context使用这个接口来调用具体的策略实现定义的算法。
■ ConcreteStrategy：具体的策略实现，也就是具体的算法实现。
■ Context：上下文，负责和具体的策略类交互。通常上下文会持有一个真正的策略实现，上下文还可以让具体的策略类来获取上下文的数据，甚至让具体的策略类来回调上下文的方法。
策略模式的功能是把具体的算法实现从具体的业务处理中独立出来，把它们实现成为单独的算法类，从而形成一系列的算法，并让这些算法可以相互替换。策略模式的重心不是如何来实现算法，而是如何组织、调用这些算法，从而让程序结构更灵活，具有更好的维护性和扩展性。
策略模式的本质：分离算法，选择实现。
仔细思考策略模式的结构和实现的功能，会发现，如果没有上下文，策略模式就回到了最基本的接口和实现了，只要是面向接口编程的，那么就能够享受到接口的封装隔离带来的好处。
观察者模式（Observer）
观察者模式： 定义对象间的一种一对多的依赖关系。当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
概念很清晰，我们举个例子来理解一下观察者模式的含义，我们都在新浪微博中关注过某一位明星（假设，当然很多人已经不玩微博了），每当这位明星发布一条动态时候，他的粉丝就都会知道。
在前面描述的订阅报纸的例子里面，对于报社来说，在一开始，它并不清楚究竟有多少个订阅者会来订阅报纸，因此，报社需要维护一个订阅者的列表，这样，当报社出版报纸的时候，才能够把报纸发放到所有的订阅者手中。对于订阅者来说，订阅者也就是看报的读者，多个订阅者会订阅同一份报纸。
这就出现了一个典型的一对多的对象关系，一个报纸对象，会有多个订阅者对象来订阅；当报纸出版的时候，也就是报纸对象改变的时候，需要通知所有的订阅者对象。那么怎么来建立并维护这样的关系呢？
观察者模式可以处理这种问题。观察者模式把这多个订阅者称为观察者：Observer，多个观察者观察的对象被称为目标：Subject。
一个目标可以有任意多个观察者对象，一旦目标的状态发生了改变，所有注册的观察者都会得到通知，然后各个观察者会对通知作出相应的响应，执行相应的业务功能处理，并使自己的状态和目标对象的状态保持一致。
■ Subject：目标对象，通常具有如下功能。
◆ 一个目标可以被多个观察者观察。
◆ 目标提供对观察者注册和退订的维护。
◆ 当目标的状态发生变化时，目标负责通知所有注册的、有效的观察者。
■ Observer：定义观察者的接口，提供目标通知时对应的更新方法，这个更新方法进行相应的业务处理，可以在这个方法里面回调目标对象，以获取目标对象的数据。
■ ConcreteSubject：具体的目标实现对象，用来维护目标状态，当目标对象的状态发生改变时，通知所有注册的、有效的观察者，让观察者执行相应的处理。
■ ConcreteObserver：观察者的具体实现对象，用来接收目标的通知，并进行相应的后续处理，比如更新自身的状态以保持和目标的相应状态一致。
备忘录模式（Memento）
备忘录模式： 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。备忘录模式又被称为快照（Snapshot）模式
一个备忘录是一个对象，它存储另一个对象在某个瞬间的内部状态，后者被称为备忘录的原发器。
备忘录模式的功能，首先是在不破坏封装性的前提下，捕获一个对象的内部状态。这里要注意两点，一个是不破坏封装性，也就是对象不能暴露它不应该暴露的细节；另外一个是捕获的是对象的内部状态，而且通常还是运行期间某个时刻对象的内部状态。
其实备忘录模式很好理解，比如游戏存档，我们玩游戏的时候肯定有存档功能，旨在下一次登录游戏时可以从上次退出的地方继续游戏，或者对复活点进行存档，如果挂掉了则可以读取复活点的存档信息重新开始。与之相类似的就是数据库的事务回滚，或者重做日志redo log等。
访问者模式（Visitor）
访问者模式： 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式是一种将数据操作和数据结构分离的设计模式。
访问者模式可以说是最复杂的设计模式，并且使用频率不高，《设计模式》的作者评价为：大多情况下，你不需要使用访问者模式，但是一旦需要使用它时，那就真的需要使用了。
Visitor： 接口或者抽象类，定义了对每个 Element 访问的行为，它的参数就是被访问的元素，它的方法个数理论上与元素的个数是一样的，因此，访问者模式要求元素的类型要稳定，如果经常添加、移除元素类，必然会导致频繁地修改 Visitor 接口，如果出现这种情况，则说明不适合使用访问者模式。
VisitorA、VisitorB： 具体的访问者，它需要给出对每一个元素类访问时所产生的具体行为。
Element： 元素接口或者抽象类，它定义了一个接受访问者（accept）的方法，其意义是指每一个元素都要可以被访问者访问。
ElementA、ElementB： 具体的元素类，它提供接受访问的具体实现，而这个具体的实现，通常情况下是使用访问者提供的访问该元素类的方法。
ObjectStructure： 定义当中所提到的对象结构，对象结构是一个抽象表述，它内部管理了元素集合，并且可以迭代这些元素提供访问者访问。
[设计模式23]-访问者模式-Visitor Pattern - 简书 (jianshu.com)
中介者模式（Mediator）
中介者模式： 用一个中介对象来封装一系列的对象交互。中介者使得各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
有了中介者以后，所有的交互都封装到中介者对象里面，各个对象就不再需要维护这些关系了。扩展关系的时候也只需要扩展或修改中介者对象就可以了。
中介者模式的结构如下图所示：
■ Mediator：中介者接口。在里面定义各个同事之间交互需要的方法，可以是公共的通信方法，比如changed方法，大家都用，也可以是小范围的交互方法。
■ ConcreteMediator：具体中介者实现对象。它需要了解并维护各个同事对象，并负责具体的协调各同事对象的交互关系。
■ Colleague：同事类的定义，通常实现成为抽象类，主要负责约束同事对象的类型，并实现一些具体同事类之间的公共功能，比如，每个具体同事类都应该知道中介者对象，也就是具体同事类都会持有中介者对象，都可以定义到这个类里面。
■ ConcreteColleague：具体的同事类，实现自己的业务，在需要与其他同事通信的时候，就与持有的中介者通信，中介者会负责与其他的同事交互。
简单地理解，中介者模式就可以理解为消息总线的概念。 中介者的功能非常简单，就是封装对象之间的交互。 如果一个对象的操作会引起其他相关对象的变化，或者是某个操作需要引起其他对象的后续或连带操作，而这个对象又不希望自己来处理这些关系，那么就可以找中介者，把所有的麻烦扔给它，只在需要的时候通知中介者，其他的就让中介者去处理就可以了。
代理模式和中介者模式
代理模式是结构型设计模式，它有很多种类型，主要是在访问对象时引入一定程度的间接性，由于有间接性，就可以附加多种的用途，比如进行权限控制。中介者模式则是为了减少对象之间的相互耦合。虽然网上有很多代理模式和中介者模式的对比，但是在我看来这两者实际上并没有可比性，只是看起来有些类似罢了。
设计模式（十四）中介者模式 - 简书 (jianshu.com)