【设计模式】职责链模式系统应用

应用背景: 系统内存在着多种不同类型的充值类型及方式，例如资讯类型充值、全字段类型充值、接口类型充值、总类型充值等方式，在获取实例对象时，通过程序优化 运行基础的职责链模式的应用来摒弃大量判断逻辑

示例:

如下方法最下面的注释部分是最基础的写法 ， 通过引入设计模式的应用， 让该方法简化至一条语句完成

该方法的作用是通过int类型的充值类型获取对应的实例对象。

接下来看一下每个子类是如何处理返回实体对象的:

** 根据实际业务的应用频次，这里限制了不同充值类型链接后的顺序，我以资讯充值为起点来编写

子类一:

注意上述getSysPrivRecharge()方法的逻辑编写，当符合TYPE的要求时，则立即返回所需要的实体对象，若不符合要求，则向下传递。我这里命令向下传递至全字段充值类型以参与判断的验证工作。

子类二:

同样该实体类也重写了getSysPrivRecharge()的方法，如果满足判断条件则立即返回，若不满足条件则继续按照业务设计向下传递至其他子类的实际逻辑

功能: 职责链模式主要用来处理"客户端发出一个请求，有多个对象都有机会来处理这一个请求，但是客户端不知道究竟谁会来处理他的请求"这样的情况。请求者和接收者解耦，这样就可以动态地切换和组合接收者了。

对于职责链模式可以选择如果有实体类处理就立即返回(如系统中示例程序),也可以设计成每个职责对象对这个请求都进行一定的功能处理，从而形成一个处理请求的功能链。

** 在职责链模式中，请求不一定会被处理，因为可能没有合适的处理者，请求在职责链中从头传递到尾，每个处理对象都判断不属于自己处理，最后请求就没有对象来处理。因此可以在职责链的末端始终加上一个不支持此功能处理的职责对象，这样最后就会存在收尾的逻辑，例如本职责链没有对象处理这个请求。

综上优缺点:

优点

1、请求者和接收者松散耦合 : 请求者并不知道接收者是谁，也不知道具体如何处理，请求者只是负责向职责链发出请求。每个职责对象不需要管请求者或者是其他的职责对象，只负责处理自己的部分，其他的就交给其他的职责对象去处理。 --> 请求者和接收者时完全解耦的。

2、动态组合职责 :  分散到单独的职责对象中，使用时可以动态组合职责形成职责链，从而可以灵活的给对象分配职责，也可以灵活的实现和改变对象的职责。

缺点

1、产生大量细粒度的对象 

因为把功能处理分散到单独的职责对象中，要把整个业务处理完，需要很多职责对象的组合，会产生大量的细粒度职责对象

2、不一定能被处理

有可能整个链全部完成后都没有职责对象处理它。应该提供默认的处理，并且构建的链的有效性

**本质: 分离职责，动态组合 [是职责链模式的精华所在]