胖虎白话学习设计模式之责任链设计模式(Chain of Responsibility)

本是古典何须时尚 2022-09-20 08:48 141阅读 0赞

胖虎白话学习设计模式之责任链设计模式（Chain of Responsibility）

记录胖虎学习设计模式过程，不许勿喷，转载请注明出处!

**http://blog.csdn.net/ljphhj**  
  
  
**1.存在问题**  
 开发中我们经常会遇到一种情况，我们希望减少对象间的责任，从而来降低对象之间的耦合程度，使系统更容易修改，客户类只能访问对象的可见接口，而无需关心对象的实现细节（或者说由哪个类来实现）.  
  
 （PS：有知道更多的问题，希望可以给我留言哈！）  
 那么引入解决方法：责任链设计模式  
  
  
**2.责任链设计模式（Chain of Responsibility）**  
  
  
 责任链设计模式主要用于：让每个类对象决定自己是否处理请求，或者沿着链传递请求给其他对象，这样避免发送者与其接收者之间的耦合度过高!  
  
 UML图讲解责任链设计模式：  
  
![SouthEast][]  
  
 图1：说明了责任链模式的实现方式  
  
  
 图中所示的三个实现类都可以处理Client类提交的请求，但是三个实现类都可以决定是否要处理请求，或者交给类中包含的“successor”来担任处理请求的任务  
 而Client类只能访问这三个类的公共接口方法“handleRequest()”，降低了Client类跟这三个类的耦合程度.  
  
  
  
**3.举个例子来讲这个责任链设计模式的做法和它的好处**  
  
 例子：最近老师的公司“学立方”要我们做一个企业ERP系统，去了解需求之后得知，公司的大体架构如下  
 "馆"->"中心"->"处"->"站"（明显的层级关系，从大到小,像金字塔一样，馆位于最上层）  
  
![SouthEast 1][]  
  
 图2：该公司的层级关系  
  
 问题来了，如果"站"这边需要申请采购一些设备，金额x元  
 当0<x<500(元)：那么“处”就可以审批处理，直接给它钱.  
 当500<=x<=5000(元):那么需要“中心”才能够处理了  
 当5000<x(元):这时候必须由“馆”级才能够审批是否购进设备了  
  
  
  
 那么相当于说：一个采购设备的Request过来，“处”.“中心”."馆"都可以处理该Request，但是当处理不了或者不想处理的时候，可以交由自己的Successor(继任者)来处理该请求

![SouthEast 2][]

**BuyRequest:**

package cn.xym.test;
    
    
    		public class BuyRequest {
    			private String goodsName;
    			private double price;
    			public BuyRequest(double price, String goodsName) {
    				this.price = price;
    				this.goodsName = goodsName;
    			}
    			public String getGoodsName() {
    				return goodsName;
    			}
    			public void setGoodsName(String goodsName) {
    				this.goodsName = goodsName;
    			}
    			public double getPrice() {
    				return price;
    			}
    			public void setPrice(double price) {
    				this.price = price;
    			}
    
    
    		}

**AbstractHandler：**

package cn.xym.test;
    
    
    	public abstract class AbstractHandler {
    		protected AbstractHandler successor;
    		public abstract boolean handleRequest(BuyRequest request);
    		public abstract boolean passRequest(BuyRequest request);
    	}

**Department:**

package cn.xym.test;
    
    
    	public class Department extends AbstractHandler{
    		public Department(AbstractHandler successor) {
    			this.successor = successor;
    		}
    		@Override
    		public boolean handleRequest(BuyRequest request) {
    			if (request.getPrice() > 0 && request.getPrice() < 500){
    				//处理代码块	
    				System.out.println("处进行了请求的处理");
    				return true;
    			}
    			return passRequest(request);
    		}
    		@Override
    		public boolean passRequest(BuyRequest request) {
    			if (this.successor == null){
    				return false;
    			}
    			return this.successor.handleRequest(request);
    		}
    	}

**Center：**

package cn.xym.test;
    
    
    	public class Center extends AbstractHandler {
    		public Center(AbstractHandler successor) {
    			this.successor = successor;
    		}
    		@Override
    		public boolean handleRequest(BuyRequest request) {
    			if (request.getPrice() >= 500 && request.getPrice() <= 5000){
    				//处理代码块	
    				System.out.println("中心进行了请求的处理");
    				return true;
    			}
    			return passRequest(request);
    		}
    		@Override
    		public boolean passRequest(BuyRequest request) {
    			if (this.successor == null){
    				return false;
    			}
    			return this.successor.handleRequest(request);
    		}
    	}

**Mansion:**

package cn.xym.test;
    
    
    	public class Mansion extends AbstractHandler{
    		public Mansion(AbstractHandler successor) {
    			this.successor = successor;
    		}
    		@Override
    		public boolean handleRequest(BuyRequest request) {
    			if (request.getPrice() > 5000){
    				//处理代码块	
    				System.out.println("馆进行了请求的处理");
    				return true;
    			}
    			return passRequest(request);
    		}
    		@Override
    		public boolean passRequest(BuyRequest request) {
    			if (this.successor == null){
    				return false;
    			}
    			return this.successor.handleRequest(request);
    		}
    	}

这样子，处理完了之后，“站”级别想要购买设备的时候，只需要提交请求给上级，至于上级处理请求还是交给上上级处理，这些就都不是Client类要关心的内容了  
  
**4.职责链的缺点和优点**  
  
  
让我们继续回到上面的例子，我们发现，如果一个BuyRequest,它购买的Price超过了5000元，那么这时候要经过  
Department->Center->Mansion,最终由Mansion处理，而传递工作之后，Department和Center，他们就成了**垃圾对象**。  
也就是说，他们在实际的处理中，并没有发挥任何的作用。那么**当这个责任链结构比较长，比较复杂的话**，会产生很多的内存垃圾对象。  
这也就是职责链的最大缺点之所在。  
  
  
**优点：降低了耦合度**

**5.J2EE中的责任链模式的使用**

之前上面所讲的“责任链”，在网上很多网友都称为是“**纯责任链**”，那么与之对应的就是“不纯的责任链”咯  
 “**不纯的责任链**”：比如一个请求被捕获后，每个具体处理者都尝试去处理它，不管结果如何都将请求再次传递下去。（而不像“纯责任链”要么处理要么传递）  
 那么典型的应用就是过滤器Filter，往大了看就是Spring框架的使用就是基于责任链模式的  
 当你从spring的的context中得到这个authFilter的时候，你其实得到了一条链，当你调用authFilter的方法是，这个 调用会沿着链向下传递。到目前为止.  
  
 **(ps:有其他的好例子，希望可以给我留言，学习哈！)**

[SouthEast]: /images/20220828/0303572a4f4f49d8aaa2a0f6eb511519.png
[SouthEast 1]: /images/20220828/c679140d23844a5683adf1f715e5c5e9.png
[SouthEast 2]: /images/20220828/de9e5aa683254983ab836f3dc854d444.png