设计模式学习笔记之六:责任链模式

我们公司使用的Enovia PLM系统是基于SOA架构的,PLM不仅仅是SAP的主数据源头,同时还需要跟其他的系统(例如供应商的DAM系统及公司的AS400系统)保持交互,系统跟系统的数据交互通过Web Service基于SOAP来实现,具体来说,PLM需要跟如下系统保持交互:

子系统 地区/功能
AFS1 中国,意大利
AFS2 北美
AS400 遗留系统
DAM 供应商
ISR 零售

PLM发送物料主数据到SAP是通过XML文件这种载体的,SAP有个PF(PI)系统专门读取PLM生成在固定共享文件夹的文件来接受数据,PI需要使用XSLT文件来作为转换文件,把PLM生成的XML转换成SAP能够读懂的格式,这里就引出了我们的主角,XSLT的transformaion文件,要知道每个ERP(AFS1,AFS2,AS400,DAM,ISR)的transformation文件内容都不一样,而且一个物料可以发送到不同的系统,只要这个物料的内容符合一定的要求,现在意大利的用户有一个需求,就是当我发送一个物料的时候,PLM系统应该能够基于每个ERP系统的规则对这个物料进行检验,如果合乎规则就应该把这个物料发送到相应系统,否则,不允许发送到相应系统。也就是说,物料1可能可以发送到AFS1,AFS2和AS400,物料2有可能只能发送到AFS1,而这一切都应该在java代码里面进行验证。

基于以上需求,我觉得责任链设计模式可以解决以上问题。

责任链模式的定义是这样的:

责任链模式是一种设计模式。在责任链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任。

基于对公司数据的保护,在这里我就不把项目中的代码贴出来了,我自己写了一个简单的责任链模式来阐述它的结构,跟我在公司写代码的习惯一样,我先画个UML类图:

抽象基类Chain

package com.singland.dp.chainofresponsibility;

public abstract class Chain {

    private Chain nextNode;

    protected Chain getNextNode() {
        return nextNode;
    }

    protected void setNextNode(Chain nextNode) {
        this.nextNode = nextNode;
    }

    public abstract void handleRequest(int num);
}

4个节点类

package com.singland.dp.chainofresponsibility;

public class ChainNode1 extends Chain {

    @Override
    public void handleRequest(int num) {
        if (num < 10) {
            System.out.println("ChinaNode1 take in charge the number less than 10");
        } else {
            Chain nextNode = getNextNode();
            if (nextNode != null) {
                nextNode.handleRequest(num);
            }
        }
    }
}
package com.singland.dp.chainofresponsibility;

public class ChainNode2 extends Chain {

    @Override
    public void handleRequest(int num) {
        if (num >=10 && num < 20) {
            System.out.println("ChinaNode2 take in charge the number less than 20");
        } else {
            Chain nextNode = getNextNode();
            if (nextNode != null) {
                nextNode.handleRequest(num);
            }
        }
    }
}
package com.singland.dp.chainofresponsibility;

public class ChainNode3 extends Chain {

    @Override
    public void handleRequest(int num) {
        if (num >= 20 && num < 30) {
            System.out.println("ChinaNode3 take in charge the number less than 30");
        } else {
            Chain nextNode = getNextNode();
            if (nextNode != null) {
                nextNode.handleRequest(num);
            }
        }
    }
}
package com.singland.dp.chainofresponsibility;

public class ChainLastNode extends Chain {

    @Override
    public void handleRequest(int num) {
        System.out.println("Why I‘m here, it seems the number is greater than 30 !");

    }
}

测试类

package com.singland.dp.chainofresponsibility;

import org.junit.Test;

public class MyTest {

    @Test
    public void test() {
        //assemble chain of responsibility
        Chain node1 = new ChainNode1();
        Chain node2 = new ChainNode2();
        Chain node3 = new ChainNode3();
        Chain lastNode = new ChainLastNode();
        node1.setNextNode(node2);
        node2.setNextNode(node3);
        node3.setNextNode(lastNode);

        //use chain of responsibility
        node1.handleRequest(200);
    }
}

在测试类里面,当责任链组装好了之后,流程图看起来就是这个样子的:

这样,不管你在测试类里面输入什么样的数字,责任链条里面都一定会有一个节点根据你的数字大小来处理,而客户端本身并不知道具体是哪个节点处理了这个请求,客户端只需要知道请求一定会被某个节点处理。

责任链模式的好处是:将业务逻辑代码依据条件分离开,单个业务逻辑块的修改不影响其他业务逻辑块,对于节点的修改不会造成客户端的调用代码的改变,实现了松耦合;可以动态地组织和分配责任。

时间: 2024-11-05 22:46:49

设计模式学习笔记之六:责任链模式的相关文章

PHP设计模式学习笔记: 责任链模式(Chain of Responsibility)

// 抽象书本类 abstract class AbstractBookTopic { abstract function getTopic(); abstract function getTitle(); abstract function setTitle($title_in); } // 书本类,继承自抽象书本类 class BookTopic extends AbstractBookTopic { private $topic; private $title; function __co

设计模式学习笔记之责任链模式

责任链模式 使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系.将这些对象连成一条链,并沿着这条链检查该请求,并对其进行处理,或者将它传递给下一个对象. 责任链模式有两个角色组成: 抽象处理者角色:它定义了一个处理请求的接口.当然对于链子的不同实现,也可以在这个角色中实现后继链. 具体处理者角色:实现抽象处理者定义的接口,并处理它所负责的请求. 下面是<设计模式>中给出的适用范围:    1) 有多个的对象可以处理一个请求,哪个对象处理该请求运行时刻自动确定.    2)

大话设计模式读书笔记--19.责任链模式

定义 责任链模式定义: 使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系,将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它 比如: 员工小张向组长申请加薪, 组长没这个权利并将请求告诉部长,部长同意了小张的加薪请求 模式结构 代码实现 场景: 经理可以批准请假, 经理的上级是总监, 总监可以批准加薪 代码实现:点击下载 优点 1.客户端不知道哪一个对象最终处理请求,在不影响客户端的情况下可以动态的重新组织和分配责任 2.链中的对象并不知道链的结构,只需保持

Java设计模式(九)责任链模式 命令模式

(十七)责任链模式 责任链模式的目的是通过给予多个对象处理请求的机会,已解除请求发送者与接受者之间的耦合关系.面对对象的开发力求对象之前保持松散耦合,确保对象各自的责任最小化,这样的设计可以使得系统更加容易修改,同时降低产生缺陷的风险. public class ChainTest { public static void main(String[] args) { String pass1="123456"; String pass2="123456"; Stri

设计模式-(15)责任链模式 (swift版)

一,概念: 责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链.这种模式给予请求的类型,对请求的发送者和接收者进行解耦.这种类型的设计模式属于行为型模式.在这种模式中,通常每个接收者都包含对另一个接收者的引用.如果一个对象不能处理该请求,那么它会把相同的请求传给下一个接收者,依此类推. 主要解决职责链上的处理者负责处理请求,客户只需要将请求发送到职责链上即可,无须关心请求的处理细节和请求的传递,所以职责链将请求的发送者和请求的处理者解耦了.

java23种设计模式之十:责任链模式

最近在学习netty中发现其中用到了责任链模式,然后结合自己在写代码中遇到了大量写if...else的情况,决定学习一下责任链模式. 一.什么样的场景下会选择用责任链模式 我们在进行业务逻辑判断时,需要根据传入参数类型的不同做出不同的处理,如果在传入的参数类型相对较少的情况时,可以用if...else来做判断,这样的确是没有什么问题的,但是如果后期由于业务系统的扩展,导致参数类型会随之延伸出很多种不同的处理,这时就需要用责任链模式来抒代码重构,这样会让代码封装的更好.更简洁,阅读性更强,后期如果

设计模式学习笔记之装饰者模式

装饰者模式     动态的将责任附加到对象上.若要扩展功能,装饰者模式提供了比继承更有弹性的替代方案. 说明: 1.装饰者和被装饰者对象有相同的超类型: 2.可以用一个或者多个装饰者包装一个对象: 3.既然装饰者和被装饰者对象有相同的超类型,所以在任何需要原始对象(被装饰者)的场合,可以用装饰过的对象代替它: 4.装饰者可以在委托被装饰者的行为之前 与 / 或 之后,加上自己的行为,以达到特定的目的: 5.对象可以在任何时候被装饰,所以可以在运行时动态地.不限量地用你喜欢的装饰者来装饰对象. 在

【设计模式学习笔记】 之 状态模式

简介: 每种事物都有不同的状态,不同的状态会有不同的表现,通过更改状态从而改变表现的设计模式称为状态模式(state pattern) 下边会通过多个例子进行讲述,会有一些代码重用的类,请注意包名! 举例1: 人有多种心情,不同的心情会有不同的表现,这里先使用分支判断写个小例子 创建一个Person类,它持有一个表示心情的字符串,通过设置这个字符串并对这个字符串进行判断来决定产生不同的行为 1 package com.mi.state.state1; 2 3 /** 4 * 人类,拥有一个状态属

java设计模式(五)责任链模式

很多对象有每个对象对其下家的引用而连接起来形成一条链,请求在这条链上传递,直到链上某个对象决定处理此请求,应用场景如单位审批流程等. 要点:1)抽象处理者角色:定义处理请求接口及设定下家引用    2)具体处理着角色:具体处理请求或选择将请求传给下家 1.抽象处理者角色类,定义处理请求接口及下家引用 public abstract class PriceHandle { protected PriceHandle successor; public void setSuccessor(Price