模板方法模式
定义一个操作中算法的框架，而将一些步骤延迟到子类中，使得子类可以改变算法的结构，即可重新定义该算法中的某些特定步骤。
优点及适用场景：
- 容易扩展
- 便于维护
- 比较灵活
在多个子类拥有相同的方法，并且这些方法逻辑相同时，可以考虑使用模板方法模式。
中介者模式
用一个中介者对象封装一系列的对象交互，中介者使各个对象显示地相互作用，从而使耦合松散，而且可以独立地改变它们之间的交互。
优点：
- 适当的使用中介者模式可以避免同事类之间的过度耦合，使得各同事类之间可以相对独立地使用
- 可以使对象间一对多的关联关系转变为一对一，使对象间的关系易于理解和维护
- 可以将对象的行为和协作进行抽象，能够比较灵活的处理对象间的相互作用
适用场景：
一般来说适用于将同事类之间网状结构的关系转换为星状结构。
观察者模式
定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对对象都会得到通知并自定更新。
观察者与被观察者之间是属于轻度的关联关系，并且是抽象耦合的，这样，对于两者来说都比较容易进行扩展。
观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。同时，这也算是观察者模式的一个缺点，由于是链式触发，当观察者数量过多时，性能是一个问题。
访问者模式
封装某些作用于某种数据结构中各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
优点：
- 符合单一职责原则：凡是适用访问者模式的场景中，元素类中需要封装在访问者中的操作必定是与元素类本身关系不大且是易变的操作，适用访问者模式一方面符合单一职责模式，另一方面，封装的操作通常是易变的，在发生变化时，可以在不改变元素本身的情况下实现扩展。
- 扩展性良好：元素可以通过接受不同的访问者来实现对不同操作的扩展。
适用场景： - 假如一个对象中存在着一些与本对象不相干（或者关系较弱时）的操作，为了避免污染这个对象，可以使用访问者模式来把这些操作封装到访问者中去。
- 假如一组对象中，存在着相似的操作，为了避免出现大量重复的代码，也可以将这些重复的代码封装到访问者中去。
但是访问者模式并不是那么完美，它的致命缺陷是：增加新的元素类比较困难。访问者模式比较适用于已有功能的重构。
命令模式：
将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。顾名思义，命令模式就是对命令的封装，优缺点如下：
- 封装性好
- 扩展性好
缺点是如果命令很多，开发起来就很麻烦。
适用场景：
对于大多数请求-响应模式的功能，比较适合命令行模式。
责任链模式
使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
优缺点：
- 责任链模式与if...else...相比，它的耦合性要低一些，当责任链比较长时，性能问题比较严重。
适用场景：
假如使用if...else...语句来组织一个责任链感到力不从心时，可以采用责任链模式。
