命令模式,职责链模式,享元模式,解释器模式总结

命令模式,职责链模式,享元模式,解释器模式总结

 

 

行为请求者与行为实现者的紧耦合问题。
对请求排队或记录请求日志，以及支持可撤销的
操作等行为时，
让编程融入生活。
---------------------------------------------------
命令模式(Command)：将一个请求封装为一个对象，从而
使你可用不同的请求对客户进行参数化；对请求排队或记录
请求日志，以及支持可撤销的操作。
命令模式的优点:
第一，它能较容易地设计一个命令队列；第二，在需要的情况下，
可以较容易地将命令记入日志，第三，允许接收请求的一方决定
是否要否决请求。

第四，可以容易地实现对请求的撤销和重做；第五，由于加进新的
具体命令类不影响其他的类，因此增加新的具体命令类很容易。
命令模式把请求一个操作的对象与知道怎么执行一个操作的对象
分割开。
敏捷开发原则告诉我们，不要为代码添加基于猜测的，实际不需要
的功能。如果一个清楚一个系统是否需要命令模式，一般就不要着急
去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，
只有在真正需要如撤销/恢复操作等功能时，把原来的代码重构为
命令模式才有意义。
-----------------------------------------------
职责链模式
（Chain of Responsibility）
使多个对象都有机会处理请求，从而避免请求的发送者
和接收者之间的耦合关系。将这个对象连成一条链，并沿
着这条链传递该请求，直到有一个对象处理它为止。
当客户提交一个请求时，请求是沿链传递直至有一个ConcreteHandler
对象负责处理它。
接收者和发送者都没有对方的明确信息，且链中的对象自己也并不知道
链的结构。
结果是职责链可简化对象的相互连接，它们仅需保持一个指向其后继者
的引用，而不需保持它所有的候选接受者的引用。
随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。
一个请求极有可能到了链的末端都得不到处理，或者因为没有正确配置而
得不到处理。
-----------------------------------------------
尽管一个系统分割成许多对象通常可以增加其可复用性，但是对象间相互
连接的激增又会降低其可复用性了。
大量的连接使得一个对象不可能在没有其他对象的支持下工作，系统表现
为一个不可分割的整体，所以，对系统的行为进行任何较大的改动就十分
困难了。
中介者模式（Mediator）,用一个中介对象来封装一系列的对象交互。中介
者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地
改变它们之间的交互。
中介者模式优缺点：
中介者模式很容易在系统中应用，也很容易在系统中误用，当系统出现了
‘多对多’交互复杂的对象群时，不要急于使用中介者模式，而先反思你
的系统在设计上是不是合理。
中介者的出现减少了各个Colleague的耦合，使得可以独立地改变和复用
各个Colleage类和Mediator，由于把对象如何协作进行了抽象，将中介作为
一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自
本身的行为转移到它们之间的交互上来，也就是站在一个更宏观的角度去看待
系统。
由于具体中介者控制了集中化，于是就把交互复杂性变为了中介者的复杂性，
这就使得中介者会变得比任何一个具体对象都复杂。
中介者模式一般应用于一组对象以定义良好量是复杂的方式进行通信的场合。
以及定制一个分布在多个类中的行为，而又不想生成太多的子类的场合。
----------------------------------------------------------------------
享元模式
Flyweight,运用共享技术有效地支持大量细粒度的对象。
在享元对象内部并且不会随环境改变而改变的共享部分，可以称为是享元对象的
内部状态，而随环境改变而改变的，不可以共享的状态就是外部状态了。事实上
，享元模式可以避免大量非常相似类的开销。在程序设计中，有时需要生成大量
细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同
的，有时就能够受大幅度地减少需要实例化的类的数量。如果能把那些参数移到
类实例的外面，在方法调用时将它们传递进来，就可以通过共享大幅度地减少单
个实例的数目。如果一个应用程序使用了大量的对象，而大量的这些对象造成了
很大的存储开销时就应该考虑使用；还有就是对象的大多数状态可以外部状态，
如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时
可以考虑使用享元模式。
--------------------------------------------------------------------------
解释器模式（interpreter），给定一个语言，定义它的文法的一种表示，
并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
通常当有一个语言需要解释执行，并且可将该语言中的句子表示为一个抽象
语法树时，可使用解释器模式。  
它可以很容易地改变和扩展文法，因为该模式使用类来表示文法规则，
你可使用继承来改变或扩展该文法，也比较容易实现文法，因为定义抽象语法树中
各个节点的类的实现大体类似，这些类都易于直接编写。
不足：解释器模式为文法中的每一条规则至少定义了一个类，因此包含许多规则
的文法可能难以管理和维护。建议当文法非常复杂时，使用其他的技术如语法
分析程序或编译器生成器来处理。