@Author:云都小生(Cloudking)
概述
不知道各位小伙伴有没有看过这种剧情,有个人在XX餐厅里吃饭,突然吃到了一些不该吃的东西(例如说铁丝,反正小生我是见得多了)。这个时候,计较的人呢马上就会大喊一声“服务员!”
服务员走过来一脸懵逼,被臭骂了一顿,但是这还没完。顾客要求赔偿,这个时候就不是服务员能解决的问题了,得请经理出马了。但是这个顾客又有点过分了啊~ 提出了连经理都解决不了的问题,那接下来只能老板能解决了。
这是第一个例子,我们来了解第二个例子。
大家一定学习过异常处理的相关知识,在异常处理中也是这种指责链的方式。只要一个方法里面,捕捉了这种异常,但是自己解决不了,那么就向外抛。下一个异常解决不了,就继续外抛,直到抛给操作系统去处理。
从服务员、经理再到老板,这就是职责链的关系。
解决方案的尝试
如果我们是普通的程序员会怎么去解决呢?
我相信很多人会这么写···
if(条件1)
{
服务员的解决方法
}
else if(条件2)
{
经理的解决方法
}
else
{
老板的解决方法
}
emmm,看来小生我就是那个普通的程序员,因为如果是我,一开始也会这么去做。但是,现在我想要屌丝逆袭了!我要做不一样的程序员!
上面这种方法的确可以实现,但是,如果我们想在其中增加一个董事长的职位,解决更大的问题,就不得不去修改源代码了,这违背了“开闭原则”。
再则,我们还违背了一个原则——“单一职责原则”,我们把业务逻辑都放在同一个类里面。
那应该怎么解决呢?来看看职责链模式是怎么解决的。
角色分析
在职责链中有两个角色,一个是 抽象处理类,另一个是 具体处理类。
抽象处理类:它包含了一个对一个更高级具体处理类的引用,通过该引用,形成一条处理链,就像这样。
这个引用使继承它的每一个具体处理类都能引用下一个具体处理类。
具体处理类1:具体处理类2的引用
具体处理类2:具体处理类3的引用
具体处理类3:具体处理类4的引用
····
这样就形成了一条职责链条。
具体处理类:具体处理类实现了抽象处理类的接口,它定义了具体的处理方法。当处理的事件超过了它的职责,就会抛给下一个具体处理类。
if(能否处理该事件)
{
处理···
}
else
{
通过引用,抛给下一个具体处理类
}
设计案例
//抽象处理类
abstract class Handler {
public Handler nextHandler;
//设置下一个处理程序
public void setHandler(Handler nextHandler)
{
this.nextHandler = nextHandler;
}
//抽象处理方法
public abstract void handleRequest(String request);
}
//具体处理类:服务员
public class Waiter extends Handler{
//服务员的处理方法
public void handleRequest(String request) {
if(request.equals("等级1"))
{
System.out.println("服务员解决了该问题");
}
else
{
this.nextHandler.handleRequest(request);
}
}
}
//具体处理类:经理
public class Manager extends Handler{
public void handleRequest(String request) {
if(request.equals("等级2"))
{
System.out.println("经理解决了该问题");
}
else
{
this.nextHandler.handleRequest(request);
}
}
}
//具体处理类:老板
public class Boss extends Handler{
public void handleRequest(String request) {
System.out.println("老板解决了该问题");
}
}
//客户端类
public class Client {
public static void main(String[] args) {
Handler waiter,manager,boss;
waiter = new Waiter();
manager = new Manager();
boss = new Boss();
waiter.setHandler(manager);
manager.setHandler(boss);
waiter.handleRequest("等级1");
waiter.handleRequest("等级2");
waiter.handleRequest("等级3");
}
}
看一下这个简单的案例,就懂了。但是我写完了在思考这样一个问题,算是扩展。如果出现了一件“Boss”类都解决不了的问题,我想再增加一个更高级的具体处理类,那岂不是得去修改Boss类的业务逻辑了?
我真傻··· 后来想一想,直接把Boss类删掉,写一个新的Boss类,把里面的业务逻辑改掉。然后再增加一个新的具体处理类,不就可以了。
扩展
职责链模式还分为两种,一种是纯的职责链模式,另一种是不纯的职责链模式,区别在哪里呢?
纯的职责链模式,每次处理不了都抛给下一家。而不纯的职责链模式,可以先进行一部分的处理,然后再抛给下一家。
职责链模式的优点我们就不说了,来说说缺点。
1. 如果职责链过长,那注定会影响效率。
2. 一个请求也可能因职责链没有被正确配置而得不到处理,因为没有任何具体处理类能够处理它。
2017/12/17 10:49:00 @Author:Cloudking