设计模式笔记(8 CHAIN OF RESPONSIBILITY & COMMAND)

CHAIN OF RESPONSIBILITY(职责链)
适用性：
1.有多个对象可以处理统一请求，但是，那个对象处理要到运行时刻决定。
2.希望在不明确接收者的情况下，向多个对象中的一个提交一个请求。
3.可处理一个请求的对象集合应该被动态指定。

思考：
既然要向未知的接收者提交请求，那么就需要统一的提交界面，也就是说，所有接收者应该实现一个公共接口，来接收请求，当然Delegate可以改变这一状况。一个典型的应用环境就是GUI系统中的事件处理方法。例如，我们可以定义一个OnClick的界面，然后OnClick可以是实际接收对象的一个方法代理:
OnClick ＝ someObj.doClick;
最重要的是，OnClick和someObj.doClick之间的关系是可以动态改变的。另外，这个doClick可以向一个对象集合分发该事件，该集合也是可以动态变化的，这时它的静态结构和观察员模式很相似，但是职责链模式并不需要将事件递交给每一个接收者。观察员模式关心的是如何观察到模型的变化，职责链模式关心的是如何递交出事件。这两者还都需要关心如何接收到相应的事件，尽管接收的行为并不一样。
职责链模式需要关心每一个事件都应该被合适的一个或多个接收者处理（HOOK模式）。例如，在一个消息分派的过程中，我们需要考虑如何增减消息处理过程，以处理相关的消息，通常这些处理过程都是各不相同的行为，并且反过来可能对发送者有影响。观察员模式一般而言，应该是无扰的。
接收者常常是通过Composite模式来组织的。

COMMAND(命令)
适用性：
1.Command模式是回调函数的一个面向对象的替代品。
2.Command对象可以有和初始请求无关的生存期
3.支持取消操作
4.支持修改日志
5.用构建在原语操作上的高层操作构造一个系统。

思考：
COMMAND模式总是会关联到一个触发者。通常，它提供的是一个非常简单的接口。COMMAND对象一般而言是一个相对高级的对象，他通常可以完成一个相对完整的概念操作，好像是完成了一个事务一样。因为COMMAND比较高级，那么其内部可以安排一些相对底层的支持，例如日志活动。很多COMMAND对象也是同时提供撤销操作。
如果COMMAND应用于事务系统，并且，一个COMMAND对象对应于一个事务的话，要小心撤销语意。一般而言，不应该撤销一个事务系统中已经完成的事务。而是通过另一个反向的事务来冲抵。例如一个帐务系统，对于错误的记帐流水事务，在向系统提交以前，可以简单撤销（这可以在Command对象的撤销操作中实现，也可以简单放弃）。对于提交以后，则应该提供一个反向的撤销流水事务（不建议在撤销操作中实现），这样系统最终记录两个事务，并且后一个事务可以冲销前一个事务。进一步，如果发现历史帐务流水记录有错，一般的财务逻辑是需要用红字冲正，就更不应该采用撤销的手段了。
职责链的接收者，可以实现为COMMAND对象，当然，这并不必要。