下面的例子就是采用了上面提到的“不纯的责任链模式”。
四、举例
这个例子来源于项目中我刚刚完成的一个小功能点——“代号自动生成器”。在项目中存在很多地方，比如：员工工号、档案代号，要求客户在使用时输入。而这些代号对于一个特定的企业或者类别，往往有一定的规则。因此可以让用户在系统参数中维护一定的规则，然后通过“代号自动生成器”来给用户生成代号。
根据初期需求，用户代号中往往存在以下几种变动元素：年份、月份、日期、流水号。由于需求比较简单，因此考虑到用户可能存在其他变动元素，所以我打算在“被第一颗子弹击中”后重构一下现有的结构。下面就是我在头脑中演绎过的使用责任链模式的重构。
这里只用来说明下责任链模式的结构和使用，因此不体现功能细节。
|
//这是抽象处理者角色 public interface CodeAutoParse { //这里就是统一的处理请求使用的接口 String[] generateCode(String moduleCode, int number, String rule,String[] target) throws BaseException; } //这个为处理日期使用的具体处理者 public class DateAutoParse implements CodeAutoParse{ //获取当前时间 private final Calendar currentDate = Calendar.getInstance(); //这里用来注入下一个处理者，系统中采用的是Spring来管理的 private CodeAutoParse theNextParseOfDate; /* public String[] generateCode(String moduleCode, int number, String rule, String[] target) |
其它具体处理者也是如此的结构，每一个里面都设置有一个用来存放下一个处理者的引用，不管你有没有下一个处理者。
其实责任链模式本身的结构和使用都没有什么，就是一个继承或者实现。在处理请求的时候，按照规定去调用下一个处理者。但是怎么来维护这样一条链子呢？
《设计模式》一书中仅仅说必须自己引入它，可以参考使用list或者map来进行注册。而在上面我使用spring来管理具体处理者角色的引入。当有了新的处理者需要添加的时候，仅仅需要修改下配置文件。
五、其他
责任链模式优点，上面已经体现出来了。无非就是降低了耦合、提高了灵活性。但是责任链模式可能会带来一些额外的性能损耗，因为它要从链子开头开始遍历。
