Java责任链模式(Chain of Responsibility模式)

简介:

Chain of Responsibility定义:Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request。也就是说,来了一个请求,A类先处理,如果没有处理,就传递到B类处理,如果没有处理,就传递到C类处理,就这样象一个链条(chain)一样传递下去。

如何使用责任链模式

虽然这一段是如何使用CoR,但是也是演示什么是CoR。

有一个Handler接口: public interface Handler{   public void handleRequest(); }

这是一个处理request的事例, 如果有多种request,比如 请求帮助 请求打印 或请求格式化:

◆ 最先想到的解决方案是:在接口中增加多个请求:

 
  1. public interface Handler{

  2. public void handleHelp();

  3. public void handlePrint();

  4. public void handleFormat();

  5. }

具体是一段实现接口Handler代码:

 
  1. public class ConcreteHandler implements Handler{

  2. private Handler successor;

  3. public ConcreteHandler(Handler successor){

  4. this.successor=successor;

  5. }

  6. public void handleHelp(){

  7. //具体处理请求Help的代码

  8. }

  9. public void handlePrint(){

  10. //如果是print 转去处理Print

  11.     successor.handlePrint();

  12. }

  13. public void handleFormat(){

  14. //如果是Format 转去处理format

  15.     successor.handleFormat();

  16. }

  17. }

一共有三个这样的具体实现类,上面是处理help,还有处理Print 处理Format这大概是我们最常用的编程思路。

虽然思路简单明了,但是有一个扩展问题,如果我们需要再增加一个请求request种类,需要修改接口及其每一个实现。

◆ 第二方案:将每种request都变成一个接口,因此我们有以下代码 :

 
  1. public interface HelpHandler{

  2. public void handleHelp();

  3. }

  4. public interface PrintHandler{

  5. public void handlePrint();

  6. }

  7. public interface FormatHandler{

  8. public void handleFormat();

  9. }

  10. public class ConcreteHandler

  11. implements HelpHandler,PrintHandler,FormatHandlet{

  12. private HelpHandler helpSuccessor;

  13. private PrintHandler printSuccessor;

  14. private FormatHandler formatSuccessor;

  15. public ConcreteHandler(HelpHandler helpSuccessor,PrintHandler printSuccessor,FormatHandler             formatSuccessor)

  16. {

  17. this.helpSuccessor=helpSuccessor;

  18. this.printSuccessor=printSuccessor;

  19. this.formatSuccessor=formatSuccessor;

  20. }

  21. public void handleHelp(){

  22. …….

  23. }

  24. public void handlePrint(){this.printSuccessor=printSuccessor;}

  25. public void handleFormat(){this.formatSuccessor=formatSuccessor;}

  26. }

这个办法在增加新的请求request情况下,只是节省了接口的修改量,接口实现ConcreteHandler还需要修改。而且代码显然不简单美丽。

◆ 解决方案3:在Handler接口中只使用一个参数化方法:

 
  1. public interface Handler{

  2. public void handleRequest(String request);

  3. }

那么Handler实现代码如下:

 
  1. public class ConcreteHandler implements Handler{

  2. private Handler successor;

  3. public ConcreteHandler(Handler successor){

  4. this.successor=successor;

  5. }

  6. public void handleRequest(String request){

  7. if (request.equals("Help")){

  8. //这里是处理Help的具体代码

  9. }else

  10. //传递到下一个

  11.       successor.handle(request);

  12. }

  13. }

  14. }

这里先假设request是String类型,如果不是怎么办?当然我们可以创建一个专门类Request

◆ 最后解决方案:接口Handler的代码如下:

 
  1. public interface Handler{

  2. public void handleRequest(Request request);

  3. }

Request类的定义:

 
  1. public class Request{

  2. private String type;

  3. public Request(String type){this.type=type;}

  4. public String getType(){return type;}

  5. public void execute(){

  6. //request真正具体行为代码

  7. }

  8. }

那么Handler实现代码如下:

 
  1. public class ConcreteHandler implements Handler{

  2. private Handler successor;

  3. public ConcreteHandler(Handler successor){

  4. this.successor=successor;

  5. }

  6. public void handleRequest(Request request){

  7. if (request instanceof HelpRequest){

  8. //这里是处理Help的具体代码

  9. }else if (request instanceof PrintRequst){

  10.       request.execute();

  11. }else

  12. //传递到下一个

  13.       successor.handle(request);

  14. }

  15. }

  16. }

这个解决方案就是CoR,在一个链上,都有相应职责的类,因此叫Chain of Responsibility。

  • CoR的优点:因为无法预知来自外界的请求是属于哪种类型,每个类如果碰到它不能处理的请求只要放弃就可以。无疑这降低了类之间的耦合性。

  • CoR的缺点是效率低,因为一个请求的完成可能要遍历到最后才可能完成,当然也可以用树的概念优化。 在Java AWT1.0中,对于鼠标按键事情的处理就是使用CoR,到Java.1.1以后,就使用Observer代替CoR。 扩展性差,因为在CoR中,一定要有一个统一的接口Handler.局限性就在这里。


原文发布时间为:2018-08-30

本文作者:HARRIES

本文来自云栖社区合作伙伴“Java杂记”,了解相关信息可以关注“Java杂记”。

相关文章
|
6月前
|
设计模式 缓存 监控
Java设计模式-责任链模式(17)
Java设计模式-责任链模式(17)
|
6月前
|
存储 Java 开发者
【Java新纪元启航】JDK 22:解锁未命名变量与模式,让代码更简洁,思维更自由!
【9月更文挑战第7天】JDK 22带来的未命名变量与模式匹配的结合,是Java编程语言发展历程中的一个重要里程碑。它不仅简化了代码,提高了开发效率,更重要的是,它激发了我们对Java编程的新思考,让我们有机会以更加自由、更加创造性的方式解决问题。随着Java生态系统的不断演进,我们有理由相信,未来的Java将更加灵活、更加强大,为开发者们提供更加广阔的舞台。让我们携手并进,共同迎接Java新纪元的到来!
106 11
|
7月前
|
消息中间件 Java
【实战揭秘】如何运用Java发布-订阅模式,打造高效响应式天气预报App?
【8月更文挑战第30天】发布-订阅模式是一种消息通信模型,发送者将消息发布到公共队列,接收者自行订阅并处理。此模式降低了对象间的耦合度,使系统更灵活、可扩展。例如,在天气预报应用中,`WeatherEventPublisher` 类作为发布者收集天气数据并通知订阅者(如 `TemperatureDisplay` 和 `HumidityDisplay`),实现组件间的解耦和动态更新。这种方式适用于事件驱动的应用,提高了系统的扩展性和可维护性。
100 2
|
6月前
|
设计模式 Java
Java设计模式-工厂方法模式(4)
Java设计模式-工厂方法模式(4)
|
7月前
|
Java
"揭秘Java IO三大模式:BIO、NIO、AIO背后的秘密!为何AIO成为高并发时代的宠儿,你的选择对了吗?"
【8月更文挑战第19天】在Java的IO编程中,BIO、NIO与AIO代表了三种不同的IO处理机制。BIO采用同步阻塞模型,每个连接需单独线程处理,适用于连接少且稳定的场景。NIO引入了非阻塞性质,利用Channel、Buffer与Selector实现多路复用,提升了效率与吞吐量。AIO则是真正的异步IO,在JDK 7中引入,通过回调或Future机制在IO操作完成后通知应用,适合高并发场景。选择合适的模型对构建高效网络应用至关重要。
135 2
|
7月前
|
设计模式 XML 存储
【二】设计模式~~~创建型模式~~~工厂方法模式(Java)
文章详细介绍了工厂方法模式(Factory Method Pattern),这是一种创建型设计模式,用于将对象的创建过程委托给多个工厂子类中的某一个,以实现对象创建的封装和扩展性。文章通过日志记录器的实例,展示了工厂方法模式的结构、角色、时序图、代码实现、优点、缺点以及适用环境,并探讨了如何通过配置文件和Java反射机制实现工厂的动态创建。
【二】设计模式~~~创建型模式~~~工厂方法模式(Java)
|
7月前
|
设计模式 XML Java
【一】设计模式~~~创建型模式~~~简单工厂模式(Java)
文章详细介绍了简单工厂模式(Simple Factory Pattern),这是一种创建型设计模式,用于根据输入参数的不同返回不同类的实例,而客户端不需要知道具体类名。文章通过图表类的实例,展示了简单工厂模式的结构、时序图、代码实现、优缺点以及适用环境,并提供了Java代码示例和扩展应用,如通过配置文件读取参数来实现对象的创建。
【一】设计模式~~~创建型模式~~~简单工厂模式(Java)
|
6月前
|
JSON Java UED
uniapp:使用DCloud的uni-push推送消息通知(在线模式)java实现
以上展示了使用Java结合DCloud的uni-push进行在线消息推送的基本步骤和实现方法。实际部署时,可能需要依据实际项目的规模,业务场景及用户基数进行必要的调整和优化,确保消息推送机制在保证用户体验的同时也满足业务需求。
324 0
|
8月前
|
设计模式 监控 Java
Java中的并发编程模式与最佳实践
随着多核处理器的普及,充分利用并发和多线程成为提高软件性能的关键。Java语言通过其丰富的并发API提供了强大的支持,使得开发者能够构建高效、可靠的并发应用程序。本文深入探讨了Java并发编程的核心概念、设计模式以及在实际开发中的最佳实践,旨在帮助读者更好地理解和掌握Java并发编程,从而编写出更加高效、稳定的应用程序。
|
8月前
|
设计模式 Java 开发者
Java中的异常处理与断路器模式
Java中的异常处理与断路器模式

热门文章

最新文章