宜兴做宠物的网站,上海seo有哪些公司,电视台网站如何做新闻报道,展示型网站解决方案Java PatternDesign of GOF(四人帮力作#xff0c;享誉15年)第十五模式Java PatternDesign of GOF(四人帮力作#xff0c;享誉15年)第十五模式板桥里人 http://www.jdon.com 2002/04/21(转载请保留)Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求reque…Java PatternDesign of GOF(四人帮力作享誉15年)第十五模式Java PatternDesign of GOF(四人帮力作享誉15年)第十五模式板桥里人 http://www.jdon.com 2002/04/21(转载请保留)Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request. 也就是说来了一个请求A类先处理如果没有处理就传递到B类处理如果没有处理就传递到C类处理就这样象一个链条(chain)一样传递下去。如何使用?虽然这一段是如何使用CoR,但是也是演示什么是CoR.有一个Handler接口:public interface Handler{public void handleRequest();}这是一个处理request的事例 如果有多种request,比如 请求帮助 请求打印 或请求格式化最先想到的解决方案是在接口中增加多个请求public interface Handler{public void handleHelp();public void handlePrint();public void handleFormat();}具体是一段实现接口Handler代码public class ConcreteHandler implements Handler{private Handler successor;public ConcreteHandler(Handler successor){this.successorsuccessor;}public void handleHelp(){//具体处理请求Help的代码...}public void handlePrint(){//如果是print 转去处理Printsuccessor.handlePrint();}public void handleFormat(){//如果是Format 转去处理formatsuccessor.handleFormat();}}一共有三个这样的具体实现类上面是处理help,还有处理Print 处理Format这大概是我们最常用的编程思路。虽然思路简单明了但是有一个扩展问题如果我们需要再增加一个请求request种类,需要修改接口及其每一个实现。第二方案:将每种request都变成一个接口因此我们有以下代码 public interface HelpHandler{public void handleHelp();}public interface PrintHandler{public void handlePrint();}public interface FormatHandler{public void handleFormat();}public class ConcreteHandlerimplements HelpHandler,PrintHandler,FormatHandlet{private HelpHandler helpSuccessor;private PrintHandler printSuccessor;private FormatHandler formatSuccessor;public ConcreteHandler(HelpHandler helpSuccessor,PrintHandler printSuccessor,FormatHandler 　　　　　　　　　　　　formatSuccessor){this.helpSuccessorhelpSuccessor;this.printSuccessorprintSuccessor;this.formatSuccessorformatSuccessor;}public void handleHelp(){.......}public void handlePrint(){this.printSuccessorprintSuccessor;}public void handleFormat(){this.formatSuccessorformatSuccessor;}}这个办法在增加新的请求request情况下只是节省了接口的修改量接口实现ConcreteHandler还需要修改。而且代码显然不简单美丽。解决方案3: 在Handler接口中只使用一个参数化方法public interface Handler{public void handleRequest(String request);}那么Handler实现代码如下public class ConcreteHandler implements Handler{private Handler successor;public ConcreteHandler(Handler successor){this.successorsuccessor;}public void handleRequest(String request){if (request.equals(Help)){//这里是处理Help的具体代码}else//传递到下一个successor.handle(request);}}}这里先假设request是String类型如果不是怎么办当然我们可以创建一个专门类Request最后解决方案:接口Handler的代码如下public interface Handler{public void handleRequest(Request request);}Request类的定义:public class Request{private String type;public Request(String type){this.typetype;}public String getType(){return type;}public void execute(){//request真正具体行为代码}}那么Handler实现代码如下public class ConcreteHandler implements Handler{private Handler successor;public ConcreteHandler(Handler successor){this.successorsuccessor;}public void handleRequest(Request request){if (request instanceof HelpRequest){//这里是处理Help的具体代码}else if (request instanceof PrintRequst){request.execute();}else//传递到下一个successor.handle(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 模式进行客户端请求的猜测一个个猜测 试验。