【设计模式】——装饰模式VS职责链模式

关于装饰模式介绍,还请大家移步【设计模式】——装饰器模式VS代理模式,本文主要介绍职责链模式,比较两者的不同之处

职责链模式(行为型)

定义: 使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。

【设计模式】——装饰模式VS职责链模式_第1张图片

主要解决:职责链上的处理者负责处理请求,客户只需要将请求发送到职责链上即可,无须关心请求的处理细节和请求的传递,所以职责链将请求的发送者和请求的处理者解耦了。

何时使用:在处理消息的时候以过滤很多道。

如何解决:拦截的类都实现统一接口。

关键代码:Handler 里面聚合它自己,在 HandlerRequest 里判断是否合适,如果没达到条件则向下传递,向谁传递之前 set 进去。

应用实例: 1、红楼梦中的"击鼓传花"。 2、JS 中的事件冒泡。 3、JAVA WEB 中 Apache Tomcat 对 Encoding 的处理,Struts2 的拦截器,jsp servlet 的 Filter。

优点: 1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序,允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。

缺点: 1、不能保证请求一定被接收。 2、系统性能将受到一定影响,而且在进行代码调试时不太方便,可能会造成循环调用。 3、可能不容易观察运行时的特征,有碍于除错。

使用场景: 1、有多个对象可以处理同一个请求,具体哪个对象处理该请求由运行时刻自动确定。 2、在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。 3、可动态指定一组对象处理请求。

实现代码

public abstract class Handler {

    protected Handler successor;

    //设置继任者
    public void setSuccessor(Handler successor) {
        this.successor = successor;
    }

    public abstract void HandleRequest(int request);
}
public class ConcreteHandler1 extends Handler {
    @Override
    public void HandleRequest(int request) {
        if (request > 0 && request < 10) {
            System.out.println("ConcreteHandler1通过");
        } else {
            successor.HandleRequest(request);
        }
    }
}
public class ConcreteHandler2 extends Handler {
    @Override
    public void HandleRequest(int request) {
        if (request > 10 ) {
            System.out.println("ConcreteHandler2通过");
        }
    }
public class Client {
    public static void main(String[] args) {
        Handler handler1 = new ConcreteHandler1();

        Handler handler2 = new ConcreteHandler2();

        handler1.setSuccessor(handler2);

        int[] requests = {2, 5, 14, 22};
        for (int request : requests) {
            handler1.HandleRequest(request);
        }
    }
}

关键点:当客户提交请求时,请求是沿链传递直至有一个ConcreteHandler对象负责处理它。这使得接受者和发送者都没有对方的明确信息,且链中对象自己也并不知道链的结构。职责链可以简化对象的相互连接,它们仅需要保持一个指向其后继者的引用,而不需要保持它所有的候选接收者的引用。可以随时的增加或者修改处理一个请求的结构,增强了给对象指派职责的灵活性。

装饰VS职责链两者相同点以及不同点

相同点:都能对对象的处理进行增强

不同点:

装饰者模式 持有被装饰的对象,并具备被装饰者的行为,对其行为进行补充增强。装饰者它可以对某一类的对象进行增强,这样就避免了冗余的继承体系,使得扩展性很强。

职责链模式 每个被调用者都持有下一个被调用者的引用,客户端只需要发起一次调用即可。核心思想就是分而治之。当调用者面临的被调者太多时,为了降低逻辑复杂度,把相关的被调用者组织起来,形成一个链式的结构,被调用者之间进行调用传递(责任传递)。

职责链和装饰器模式结合体

面对日常业务开发,有一种场景,需要使用职责链和装饰器模式组合才能完成业务。如果单独只想使用一种,就特别容易将两个模式搞得界线很模糊。就用一种结合体将具体阐述下两者使用的不同之处。

【设计模式】——装饰模式VS职责链模式_第2张图片

将Component的具体逻辑从由一个对象执行,改为链路判断,符合的执行,否则传递给下者。但是装饰器Decorator并不关心具体是哪个对象执行此逻辑,只关心此逻辑执行后,它本身需要处理哪些逻辑。

具体逻辑代码,以及结果输出展示

//充当抽象角色,不应该具体实现
public interface Component {

    void Operation(int request);
}
//针对接口封装抽象类,以便后续可以设置继任者
public abstract class Handler implements Component {

    protected Handler successor;

    //设置继任者
    public void setSuccessor(Handler successor) {
        this.successor = successor;
    }
    @Override
    public abstract void Operation(int request);
}

//具体逻辑1
public class ConcreteHandler1 extends Handler {
    @Override
    public void Operation(int request) {
        if (request > 0 && request < 10) {
            System.out.println(request + "对象操作 ConcreteHandler1通过");
        } else {
            successor.Operation(request);
        }
    }

}
//具体逻辑2
public class ConcreteHandler2 extends Handler {
    @Override
    public void Operation(int request) {
        if (request > 10 ) {
            System.out.println(request + "对象操作 ConcreteHandler2通过");
        }
    }
}
//装饰抽象类继承Component
public abstract class Decorator implements Component {

    //装饰器的核心
    protected Component component;

    public void setComponent(Component component) {
        this.component = component;
    }

    @Override
    public void Operation(int request) {
        if (component != null) {
            component.Operation(request);
        }
    }
}
//装饰的具体实现类
public class ConcreteDecoratorA extends Decorator {

    @Override
    public void Operation(int request) {
        super.Operation(request);
        System.out.println("具体装饰对象A的操作");
    }
}
public class ConcreteDecoratorB extends Decorator {
    @Override
    public void Operation(int request) {
        super.Operation(request);
        System.out.println("具体装饰对象B的操作");
    }
}
public class Client {
    public static void main(String[] args) {
        //对象具体实现,但是不知道要使用链上的哪个类
        Handler handler1 = new ConcreteHandler1();

        Handler handler2 = new ConcreteHandler2();

        handler1.setSuccessor(handler2);

       ConcreteDecoratorA decoratorA = new ConcreteDecoratorA();
       ConcreteDecoratorB decoratorB = new ConcreteDecoratorB();

        decoratorA.setComponent(handler1);
        decoratorB.setComponent(decoratorA);

        int[] requests = {2, 5, 14, 22};
        for (int request : requests) {
            decoratorB.Operation(request);
        }
    }
}

【设计模式】——装饰模式VS职责链模式_第3张图片

【设计模式】——装饰模式VS职责链模式_第4张图片 

图中红色方块中,装饰和职责链融合的开始,只将职责链的顶端当做被装饰者,具体被装饰者内部的逻辑则属于职责链范围。装饰器模式,只要执行Operation(int request)方法就会对该方法执行内容增加额外处理,即增强。

总结

职责链模式:只关心被调用者之间的调用传递。

装饰器模式:它不关心外界如何调用,只注重对对象功能的加强,装饰后还是对象本身。

代理模式:重心是为了借用对象的功能完成某一流程,而非对象功能如何。 

你可能感兴趣的:(【设计模式】,职责链模式,装饰器模式)