职责链模式
链的组织是从最特殊的到最一般的，并且不能保证请求在任何情况下都回有相应。
职责链将程序中每个对象能做什么的内容隔离，即职责链减少了对象之间的耦合，每个对象都能独立操作。职责链也可用于构成主程序的对象和包含其它对象实例的对象。
适用场景：
1 具有相同方法的几个对象都适合于执行程序请求操作，但由对象决定由谁去完成操作，比把决策建立在调用代码中更合适
2 其中某个对象可能最适合处理请求，但你不想通过一些列if-else语句或switch语句去选择一个特定的对象
3 程序执行时，需要向处理选项链中添加新的对象
4 在多个对象都能执行一个请求的情况下，你不想把这些相互作用的内容放在调用程序里
链中每个对象都是“自治”的，最后一个对象决定是默认处理请求，还是抛弃
命令模式
职责链沿类链转发请求，而命令模式只将请求转发给一个特定对象。命令模式把一个申请特定操作的请求封装到一个对象中，并给该对象一个众所周知的公共接口，使客户端不用了解实际执行的操作就能产生请求，也可以使你改变操作而丝毫不影响客户端程序。
命令模式的效果：
命令模式的主要缺点是，增加了使程序散乱的小类，不过，即使有单独的单击事件，也通常都调用小的私有方法完成具体功能。最后的结果是，私有方法和我们这些小类的代码长度几乎一样，因此，构建Command类和编写较多的方法在复杂性上通常没有区别，主要区别是命令模式生成的小类更容易理解。
使用命令设计模式的另一个主要原因是，他们提供了一个便捷的存储方法并能完成Undo功能。每个命令对象都记住刚刚做过的事，并在有Undo请求时，只要计算量和内存需求不太过分，就能恢复到刚才的状态。
解释器模式
解释器模式通常描述的是，为某种语言定义一个文法，并用该文法解释语言中的语句。
解释器模式的效果：
只要在程序中使用了解释器，就是为程序的用户提供一种简单的方法来输入该语言的命令。
引进一种语言及其文法，还需要对拼错的单词或放错的文法元素做相当大范围的错误检查，除非有可用的模板代码来实现这种检查，否则要编写大量的程序。
解释器模式的优点：一旦构建好通用的分析，归纳工具，扩展或修改文法相当容易，规则建立以后也可以添加新的动词或变量。随着文法变得越来越复杂，创建的程序也越来越难以维护。
解释器在解决一般程序设计问题时不是那么通用。