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