设计模式之Chain of Responsibility(职责链)
Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request. 也就是说,来了一个请求,A类先处理,如果没有处理,就传递到B类处理,如果没有处理,就传递到C类处理,就这样象一个链条(chain)一样传递下去。 如何使用? 有一个Handler接口: public interface Handler{ 这是一个处理request的事例, 如果有多种request,比如 请求帮助 请求打印 或请求格式化: } 具体是一段实现接口Handler代码: public ConcreteHandler(Handler successor){ public void handleHelp(){ public void handlePrint(){ } 虽然思路简单明了,但是有一个扩展问题,如果我们需要再增加一个请求request种类,需要修改接口及其每一个实现。 第二方案:将每种request都变成一个接口,因此我们有以下代码 : public interface HelpHandler{ public interface PrintHandler{ public interface FormatHandler{ public class ConcreteHandler public ConcreteHandler(HelpHandler helpSuccessor,PrintHandler printSuccessor,FormatHandler formatSuccessor) public void handleHelp(){ public void handlePrint(){this.printSuccessor=printSuccessor;} public void handleFormat(){this.formatSuccessor=formatSuccessor;} } 这个办法在增加新的请求request情况下,只是节省了接口的修改量,接口实现ConcreteHandler还需要修改。而且代码显然不简单美丽。 解决方案3: 在Handler接口中只使用一个参数化方法: public ConcreteHandler(Handler successor){ public void handleRequest(String request){ } } 这里先假设request是String类型,如果不是怎么办?当然我们可以创建一个专门类Request 最后解决方案:接口Handler的代码如下: public String getType(){return type;} public void execute(){ public ConcreteHandler(Handler successor){ public void handleRequest(Request request){ } } 这个解决方案就是CoR, 在一个链上,都有相应职责的类,因此叫Chain of Responsibility. CoR的优点: 缺点是效率低,因为一个请求的完成可能要遍历到最后才可能完成,当然也可以用树的概念优化。 在Java AWT1.0中,对于鼠标按键事情的处理就是使用CoR,到Java.1.1以后,就使用Observer代替CoR 扩展性差,因为在CoR中,一定要有一个统一的接口Handler.局限性就在这里。 与Command模式区别: Command 模式需要事先协商客户端和服务器端的调用关系,比如 1 代表 start 2 代表 move 等,这些 都是封装在 request 中,到达服务器端再分解。 CoR 模式就无需这种事先约定,服务器端可以使用 CoR 模式进行客户端请求的猜测,一个个猜测 试验。 |
|