江苏省建设局网站,婚庆公司网站建设策划书.doc,91卡盟平台,枫叶建站目录1.策略模式1.1 目标1.2.内容定位1.3.定义1.4.应用场景1.5.促销优惠业务场景1.6 用策略模式实现选择支付方式的业务场景1.7 策略模式在框架源码中的体现1.8 策略模式的优缺点2 责任链模式2.1 责任链楼式的应用场景2.2 利用责任链模式进行数据校验拦截2.3 责任链模式和建造者…
目录1.策略模式1.1 目标1.2.内容定位1.3.定义1.4.应用场景1.5.促销优惠业务场景1.6 用策略模式实现选择支付方式的业务场景1.7 策略模式在框架源码中的体现1.8 策略模式的优缺点2 责任链模式2.1 责任链楼式的应用场景2.2 利用责任链模式进行数据校验拦截2.3 责任链模式和建造者模式结合使用2.4 责任链模式在源码中的体现2.5 责任链模式的优缺点1.策略模式
1.1 目标
1、 掌握策略模式和责任链模式的应用场景
2、 通过学习策略模式来消除程序中大量的if…else…和 switch语 句 ;
3、 掌握策略模式和委派模式的结合使用
4、 深刻理解责任链模式和建造者模式的结合应用
1.2.内容定位
1 、已经掌握建造者模式和委质模式的人群。
2、希望通过对策略模式的学习来消除程序中大量的冗余代码和多重条件转移语句的人群。
3、希望通过学习责任链模式宜构校验逻辑的人群。
1.3.定义
策略模式 (Strategy Pattern) 又叫也叫政策摆式 (Policy Pattern) , 它是将定义的算法家族、分 别封装起来让它们之间可以互相替换从而让算法的变化不会影响到使用算法的用户。属千行为型模式。 原 文 Define a family of algorithms,encapsulate each one,and make them interchangeable. 策略摆式使用的就是面向对象的继承和多态机制从而实现同—行为在不同场萦下具备不同实现。
1.4.应用场景
策略模式在生活场景中应用也非常多。比如—个入的交税比率与他的工资有关不同的工资水平对 应不同的税率。再比如我们在互联网移动支付的大背景下每次下单后付款前需要选择支付方式。 策略模式可以解决在有多种算法相似的情况下使用 if…else 或 switch… case 所带来的复杂性和臃肿性。在日常业务开发中策略模式适用于以下场景
1 、针对同—类型问题有多种处理方式每—种都能独立解决问题
2、 算法需要自由切换的场果
3、需要屏蔽算法规则的场果。
首先来看下策略模式的通用 UML 类图 从 UML 类图中我们可以看到策略摆式主要包含三种角色
上下文角色 (Context) : 用来操作策略的上下文环境屏蔽高层模块客户端对策略 算法的 直接访问封装可能存在的变化
抽象策略角色 (Strategy) : 规定策略或算法的行为
具体策略角色 (ConcreteStrategy) : 具体的策略或算法实现。 注意 策略模式中的上下文环境 (Context) , 其职责本来是隔离客户端与策略类的耦合 让客户端完全与上下文环境 沟通 无需关系具体策略。 1.5.促销优惠业务场景
优惠策略会有很多种可能如 领取优惠券抵扣、返现促销、拼团优惠。下面我们用代码来模拟
首先我们创建—个促销策略的抽象 PromotionStrategy : /*** 促销策略抽象 */public interface IPromotionStrategy {void doPromotion();}然后分别创建优惠券抵扣策略 CouponStrategy 类、返现促销策略 CashbackStrategy 类、拼团优惠策略 GroupbuyStrategy 类和无优惠策略 EmptyStrategy 类 public class CouponStrategy implements IPromotionStrategy {public void doPromotion() {System.out.println(使用优惠券抵扣);}}CashbackStrategy 类 public class CashbackStrategy implements IPromotionStrategy {public void doPromotion() {System.out.println(返现直接打款到支付宝账号);}}GroupbuyStrategy 类 public class GroupbuyStrategy implements IPromotionStrategy {public void doPromotion() {System.out.println(5人成团可以优惠);}}EmptyStrategy 类 public class EmptyStrategy implements IPromotionStrategy {public void doPromotion() {System.out.println(无优惠);}}然后创建促销活动方案 PromotionActivity 类 public class PromotionActivity {private IPromotionStrategy strategy;public PromotionActivity(IPromotionStrategy strategy) {this.strategy strategy;}public void execute(){strategy.doPromotion();}}编写客户端测试类 public class Test {public static void main(String[] args) {PromotionActivity activity618 new PromotionActivity(new CouponStrategy());PromotionActivity activityllll new PromotionActivity(new CashbackStrategy());activity618.execute();activityllll.execute();}}运行效果如下 使用优惠券抵扣返现直接打款到支付宝账号此时小伙伴们会发现如果把上面这段则试代码放到实际的业务场景其实并不实用。因为我们做活动时候往往是要根据不同的需求对促销策略进行动态选择的并不会一次性执行多种优惠。所以我 们的代码通常会这样写 public class Test {public static void main(String[] args) {PromotionActivity promotionActivity null;String promotionKey COUPON;if (StringUtils.equals(promotionKey, COUPON)) {promotionActivity new PromotionActivity(new CouponStrategy());} else if (StringUtils.equals(promotionKey, CASHBACK)) {promotionActivity new PromotionActivity(new CashbackStrategy());}promotionActivity.execute();}}这样改造之后满足了业务需求客户可根据自己的需求选择不同的优惠策略了。但是经过—段 时间的业务积累我们的促销活动会越来越多。千是我们的程序猿小哥哥就忙不来了每次上活动之前都要通宵改代码而且要做重复测试判断逻辑可能也变得越来越复杂。这时候我们是不需要思考 代码是不是应该重构了回顾我们之前学过的设计模式应该如何来优化这段代码呢其实我们可以结 合单例模式和工厂摆式。创建 PromotionStrategyFactory 类 public class PromotionStrategyFacory {private static final IPromotionStrategy EMPTY new EmptyStrategy();private static MapString, IPromotionStrategy PROMOTIONS new HashMapString, IPromotionStrategy();static {PROMOTIONS.put(PromotionKey.COUPON, new CouponStrategy());PROMOTIONS.put(PromotionKey.CASHBACK, new CashbackStrategy());PROMOTIONS.put(PromotionKey.GROUPBUY, new GroupbuyStrategy());}private PromotionStrategyFacory() {}public static IPromotionStrategy getPromotionStrategy(String promotionKey) {IPromotionStrategy strategy PROMOTIONS.get(promotionKey);return strategy null ? EMPTY : strategy;}public static SetString getPromotionKeys() {return PROMOTIONS.keySet();}private interface PromotionKey {String COUPON COUPON;String CASHBACK CASHBACK;String GROUPBUY GROUPBUY;}}这时候我们客户端代码就应该这样写了 public class Test {public static void main(String[] args) {PromotionActivity activity618 new PromotionActivity(new CouponStrategy());PromotionActivity activityllll new PromotionActivity(new CashbackStrategy());activity618.execute();activityllll.execute();}}运行效果如下 使用优惠券抵扣代码优化之后 是不是我们程序猿小哥哥的维护工作就轻松了每次上新活动不影响原来的代码 逻辑。
1.6 用策略模式实现选择支付方式的业务场景
为了加深对策略模式的理解我们再来举一个案例。 相信小伙伴们都用过支付宝、微信支付、银联 支付以及京东白条。 —个常见的应用场景就是大家在下单支付时会提示选择支付方式如果用户未选 系统也会默认好推荐的支付方式进行结算。来看一下类图下面我们用策略模式来描拟此业务场罢 创建 Payment 抽象类定义支付规范和支付逻辑代码如下 public abstract class Payment {public abstract String getName();//通用逻辑放到抽象类里面实现public MsgResult pay(String uid, double amount) {//余额是否足够if (queryBalance(uid) amount) {return new MsgResult(500, 支付失败, 余额不足);}return new MsgResult(200, 支付成功, 支付金额 amount);}protected abstract double queryBalance(String uid);}分别创建具体的支付方式支付宝 AliPay类 public class AliPay extends Payment {public String getName() {return 支付宝;}protected double queryBalance(String uid) {return 900;}}京东白条JDPay 类 public class JDPay extends Payment {public String getName() {return 京东白条;}protected double queryBalance(String uid) {return 500;}}
微信支付 WechatPay类 public class WechatPay extends Payment {public String getName() {return 微信支付;}protected double queryBalance(String uid) {return 263;}}银联支付 UnionPay 类 public class UnionPay extends Payment {public String getName() {return 银联支付;}protected double queryBalance(String uid) {return 120;}}创建支付状态的包装类 MsgResult: public class MsgResult {private int code;private Object data;private String msg;public MsgResult(int code, String msg, Object data) {this.code code;this.data data;this.msg msg;}Overridepublic String toString() {return MsgResult{ code code , data data , msg msg \ };}}创建支付策略管理类 public class PayStrategy {public static final String ALI_PAY AliPay;public static final String JD_PAY JdPay;public static final String WECHAT_PAY WechatPay;public static final String UNION_PAY UnionPay;public static final String DEFAULT_PAY ALI_PAY;private static MapString,Payment strategy new HashMapString,Payment();static {strategy.put(ALI_PAY,new AliPay());strategy.put(JD_PAY,new JDPay());strategy.put(WECHAT_PAY,new WechatPay());strategy.put(UNION_PAY,new UnionPay());}public static Payment get(String payKey){if(!strategy.containsKey(payKey)){return strategy.get(DEFAULT_PAY);}return strategy.get(payKey);}}创建订单 Order 类 public class Order {private String uid;private String orderId;private double amount;public Order(String uid, String orderId, double amount) {this.uid uid;this.orderId orderId;this.amount amount;}public MsgResult pay(){return pay(PayStrategy.DEFAULT_PAY);}public MsgResult pay(String payKey){Payment payment PayStrategy.get(payKey);System.out.println(欢迎使用 payment.getName());System.out.println(本次交易金额为 amount 开始扣款);return payment.pay(uid,amount);}}测试代码 public class Test {public static void main(String[] args) {Order order new Order(1,2020031401000323,324.5);System.out.println(order.pay(PayStrategy.UNION_PAY));}}运行结果 欢迎使用银联支付本次交易金额为324.5开始扣款MsgResult{code500, data余额不足, msg支付失败}希望通过大家耳熟能详的业务场景来举例让小伙伴们更深刻地理解策略模式。希望小伙伴们在面 试和工作体现出自己的优势。
1.7 策略模式在框架源码中的体现
首先来看JDK 中—个比较常用的比较器 Comparator 接口我们看到的—个大家常用的 compare() 方法就是一个策略抽象实现 public interface ComparatorT {int compare(T o1, T o2);}Comparator抽象下面有非常多的实现类我们经常会把 Comparator作为参数传入作为排序策略 例如 Arrays 类的 parallelSort 方法等 public class Arrays {public static void parallelSort(byte[] a) {int n a.length, p, g;if (n MIN_ARRAY_SORT_GRAN ||(p ForkJoinPool.getCommonPoolParallelism()) 1)DualPivotQuicksort.sort(a, 0, n - 1);elsenew ArraysParallelSortHelpers.FJByte.Sorter(null, a, new byte[n], 0, n, 0,((g n / (p 2)) MIN_ARRAY_SORT_GRAN) ?MIN_ARRAY_SORT_GRAN : g).invoke();}}还有 TreeMap 的构造方法 public class TreeMapK,Vextends AbstractMapK,Vimplements NavigableMapK,V, Cloneable, java.io.Serializable{public TreeMap(Comparator? super K comparator) {this.comparator comparator;}}这就是 Comparator 在JDK原码中的应用。那我们来看策略模式在 Spring源码中的应用来看 Resource 类 public interface Resource extends InputStreamSource {boolean exists();default boolean isReadable() {return true;}default boolean isOpen() {return false;}default boolean isFile() {return false;}URL getURL() throws IOException;URI getURI() throws IOException;File getFile() throws IOException;default ReadableByteChannel readableChannel() throws IOException {return Channels.newChannel(this.getInputStream());}long contentLength() throws IOException;long lastModified() throws IOException;Resource createRelative(String var1) throws IOException;NullableString getFilename();String getDescription();}我们虽然没有直接使用 Resource 类但是我们经常使用它的子类例如 /** see WritableResource* see ContextResource* see UrlResource* see ClassPathResource* see FileSystemResource* see PathResource* see ByteArrayResource* see InputStreamResource*/还有一个非常典型的场罢 Spring 的初始化也采用了策略模式不同的类型的类采用不同的初始化 策略。首先有一个 lnstantiationStrategy 接口我们来看一下涌码 public interface InstantiationStrategy {Object instantiate(RootBeanDefinition bd, Nullable String beanName, BeanFactory owner) throws BeansException;Object instantiate(RootBeanDefinition bd, Nullable String beanName, BeanFactory owner, Constructor? ctor, Nullable Object... args) throws BeansException;Object instantiate(RootBeanDefinition bd, Nullable String beanName, BeanFactory owner, Nullable Object factoryBean, Method factoryMethod, Nullable Object... args) throws BeansException;}顶层的策略抽象非常简单但是它下面有两种策略 SimplelnstantiationStrategy 和 CgIibSubclassingInsta ntiationStrategy , 我们看—下类图 打开类图我们还发现 CgIibSubclassingInstantiationStrategy 策略类还继承了 SimplelnstantiationStrategy 类说明在实际应用中多种策略之间还可以继承使用。小伙们可以作为 —个参考在实际业务场萦中可以根据需要来设计。
1.8 策略模式的优缺点
优点
1 、策略模式符合开闭原则。
2、避免使用多重条件转移语句如 if…else… 语句、 switch 语句
3、使用策略模式可以提高算法的保密性和安全性。
缺点
1 、客户端必须知道所有的策略并且自行决定使用哪一个策略类。
2、代码中会产生非常多策略类增加维护难度。
2 责任链模式
责任链模式 (Chain of Responsibility Pattern) 是将链中每一个节点看作是一个对象每个节点处理 的清求均不同且内部自动维护—个下—节点对象。当—个清求从链式的首端发出时会沿看链的路径 依次传递给每—个节点对象直至有对象处理这个清求为止。属千行为型模式。 原文Avoid coupling the sender of a request to its receiver by giving more than one object a chance to hand I e the request. Chain the receiving objects and pass the request along the chain until an object handles it. 解释使多个对象都有机会处理请求从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链 并沿着这条链传递该请求直到有一个对象处理它为止。 2.1 责任链楼式的应用场景
在日常生活中责任链梩式还是比较常见的我们平时工作处理一些事务往往是各部门协同合作的 完成莘—个任务。而每个部门都有各自的职责因此很多时候事谓完成—半便会转交给下—个部门 直到所有部门都过一渔之后事谓才能完成。还有我们平时俗话说的过五关、斩六将其实也是一种责任链。 责任链模式主要是解耦了请求与处理,客户只需将清求发送到链上即可无需关心请求的具体内容 和处理细节请求会自动进行传递直至有节点对象进行处理。
适用于以下应用场景
1 、多个对象可以处理同一清求但具体由哪个对象处理则在运行时动态决定
2、在不明确指定接收者的情况下向多个对象中的—个提交—个请求
3、可动态指定一组对象处理请求。
首先来看下责任链模式的通用 UML 类图 从 UML类图中,我们可以看到,责任链模式主要包含两种角色:
抽象处理者Handler:定义一个请求处理的方法并维护一个下一个处理节点Handler对象的 引用
具体处理者ConcreteHandler:对请求进行处理,如果不感兴趣则进行转发。
责任链模式的本质是解耦请求与处理让请求在处理链中能进行传递与被处理理解责任链模式应 当理解的是其模式道 而不是其具体实现术 责任链模式的独到之处是其将节点处理者组合成了 链式结构并允许节点自身决定是否进行请求处理或转发相当于让请求流动了起来。
2.2 利用责任链模式进行数据校验拦截
首 先 创建一个实体类Member : Datapublic class Member {private String loginName;private String loginPass;private String roleName;public Member(String loginName, String loginPass) {this.loginName loginName;this.loginPass loginPass;}}然后来看一段我们经常写的代码 public class MemberService {public static void main(String[] args) {MemberService service new MemberService();service.login(tom, 666);}public void login(String loginName, String loginPass) {if (StringUtils.isEmpty(loginName) ||StringUtils.isEmpty(loginPass)) {System.out.println(用户名和密码为空);return;}System.out.println(用户名和密码不为空可以往下执行);Member member checkExists(loginName, loginPass);if (null member) {System.out.println(用户不存在);return;}System.out.println(登录成功);if (!管理员.equals(member.getRoleName())) {System.out.println(您不是管理员没有操作权限);return;}System.out.println(允许操作);}private Member checkExists(String loginName, String loginPass) {Member member new Member(loginName, loginPass);member.setRoleName(管理员);return member;}}请问各位小伙伴你们是不是经常这么干上面的代码中主要功能是做了登录前的数据验证然 后 判断逻辑是有先后顺序的。首先做非空判断然后检查账号是否有效最终获得用户角色。然后根 据用户角色所拥有的权限再匹配是否有操作权限。那么这样的检验性代码一般都是必不可少的 但是写在具体的业务代码又显得代码非常臃肿因此我们可以用责任链模式 将这些检查步骤串联起来而且 不影响代码美观。可以使得我们在编码时可以更加专注于某一个具体的业务逻辑处理。
下面我们用责任链模式来优化一下代码首先创建一个Handler类 public abstract class Handler {protected Handler next;public void next(Handler next){ this.next next;}public abstract void doHandler(Member member);}我们分别创建非空校验ValidateHandler类、登录校验LoginHandler类和权限校验AuthHandler 类 来看代码ValidateHandler类 public class ValidateHandler extends Handler {public void doHandler(Member member) {if (StringUtils.isEmpty(member.getLoginName()) ||StringUtils.isEmpty(member.getLoginPass())) {System.out.println(用户名和密码为空);return;}System.out.println(用户名和密码不为空可以往下执行);next.doHandler(member);}}LoginHandler 类: public class LoginHandler extends Handler {public void doHandler(Member member) {System.out.println(登录成功);member.setRoleName(管理员);next.doHandler(member);}}AuthHandler 类: public class AuthHandler extends Handler {public void doHandler(Member member) {if (!管理员.equals(member.getRoleName())) {System.out.println(您不是管理员没有操作权限);return;}System.out.println(允许操作);}}接下来,修 改Memberservice中的代码,其实我们只需要将前面定义好的几个Handler根据业务需求串联起来形成一条链即可 public class MemberService {public void login(String loginName, String loginPass) {Handler validateHandler new ValidateHandler();Handler loginHandler new LoginHandler();Handler authHandler new AuthHandler();validateHandler.next(loginHandler);loginHandler.next(authHandler);validateHandler.doHandler(new Member(loginName, loginPass));}}来看客户端调用代码: public class Test {public static void main(String[] args) {MemberService memberService new MemberService();memberService.login(tom,666);}}其运行结果如下: 其实我们平时使用的很多权限校验框架都是运用这样一个原理将各个维度的权限处理解耦之后再 串联起来各自只处理各自相关的职责。如果职责与自己不相关则抛给链上的下一个Handler, 俗称踢 皮球。
2.3 责任链模式和建造者模式结合使用
因为责任链模式具备链式结构而上面代码中我们看到负责组装链式结构的角色是 MemberService ,当链式结构较长时,MemberService的工作会非常繁琐,并且MemberService代 码相对臃肿且后续更改处理者或消息类型时都必须在MemberService中进行修改,不符合开闭原 则。产生这些问题的原因就是因为链式结构的组装过于复杂,而对于复杂结构的创建很自然我们就会 想到建造者模式,使用建造者模式我们完全可以MemberService指定的处理节点对象进行自动链式组装客户只需指定处理节点对象其他任何事情都无需关心并且客户指定的处理节点对象顺序不 同 构造出来的链式结构也随之不同。我们来改造一下修改Handler的代码 public abstract class HandlerT {protected Handler next;public void next(Handler next){ this.next next;}public abstract void doHandler(Member member);public static class BuilderT{private HandlerT head;private HandlerT tail;public BuilderT addHandler(Handler handler){// do {if (this.head null) {this.head this.tail handler;return this;}this.tail.next(handler);this.tail handler;// }while (false);//真正框架中如果是双向链表会判断是否已经到了尾部return this;}public HandlerT build(){return this.head;}}}然 后 修改MemberService的代码 public class MemberService {public void login(String loginName,String loginPass){Handler.Builder builder new Handler.Builder();builder.addHandler(new ValidateHandler()).addHandler(new LoginHandler()).addHandler(new AuthHandler());builder.build().doHandler(new Member(loginName,loginPass));//用过Netty的人肯定见过}}因为建造者模式要构建的是节点处理者因此我们把Builder作为Handler的静态内部类并且因 为客户端无需进行链式组装因此我们还可以把链式组装方法next。方法设置为private使 Handler 更加高内聚代码如下 public abstract class HandlerT {protected Handler chain;private void next(Handler handler) {this.chain handler;}}通过这个案例小伙伴们应该已经感受到责任链和建造者结合的精 ITo
2.4 责任链模式在源码中的体现
首先我们来看责任链模式在JDK中的应用来看一个J2EE标准中非常常见的Filter类: public interface Filter {public void init(FilterConfig filterConfig) throws ServletException;public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException;public void destroy();}这个Filter接口的定义非常简单相当于责任链模型中的Handler抽象角色那么它是如何形成一 条责任链的呢我来看另外一个类其实在doFilte()方法的最后一个参数我们已经看到其类型是 FilterChain类 来看它的源码 public interface FilterChain {public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException;}FilterChain类中也只定义了一个doFilter()方法,那么它们是怎么串联成一个责任链的呢实际上 J2EE只是定义了一个规范具体处理逻辑是由使用者自己来实现。我们来看一个Spring的实现 MockFilterChain类: public class MockFilterChain implements FilterChain {Nullableprivate ServletRequest request;Nullableprivate ServletResponse response;private final ListFilter filters;Nullableprivate IteratorFilter iterator;public MockFilterChain() {this.filters Collections.emptyList();}public MockFilterChain(Servlet servlet) {this.filters initFilterList(servlet);}public MockFilterChain(Servlet servlet, Filter... filters) {Assert.notNull(filters, filters cannot be null);Assert.noNullElements(filters, filters cannot contain null values);this.filters initFilterList(servlet, filters);}private static ListFilter initFilterList(Servlet servlet, Filter... filters) {Filter[] allFilters ObjectUtils.addObjectToArray(filters, new ServletFilterProxy(servlet));return Arrays.asList(allFilters);}Nullablepublic ServletRequest getRequest() {return this.request;}Nullablepublic ServletResponse getResponse() {return this.response;}Overridepublic void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException {Assert.notNull(request, Request must not be null);Assert.notNull(response, Response must not be null);Assert.state(this.request null, This FilterChain has already been called!);if (this.iterator null) {this.iterator this.filters.iterator();}if (this.iterator.hasNext()) {Filter nextFilter this.iterator.next();nextFilter.doFilter(request, response, this);}this.request request;this.response response;}public void reset() {this.request null;this.response null;this.iterator null;}private static class ServletFilterProxy implements Filter {private final Servlet delegateServlet;private ServletFilterProxy(Servlet servlet) {Assert.notNull(servlet, servlet cannot be null);this.delegateServlet servlet;}Overridepublic void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {this.delegateServlet.service(request, response);}Overridepublic void init(FilterConfig filterConfig) throws ServletException {}Overridepublic void destroy() {}Overridepublic String toString() {return this.delegateServlet.toString();}}}它把链条中的所有Filter放到List中 然后在调用doFilter。方法时循环迭代List , 也就是说List 中的Filter会顺序执行。
再来看一个在Netty中非常经典的串行化处理Pipeline就采用了责任链设计模式。它底层采用双向 链表的数据结构将链上的各个处理器串联起来。客户端每一个请求的到来,Netty都认为Pipeline中 的所有的处理器都有机会处理它。因此对于入栈的请求全部从头节点开始往后传播一直传播到尾节 点才会把消息释放掉。来看一个Netty的责任处理器接口 ChannelHandler: public interface ChannelHandler {// 当 handler被添加到真实的上下文中并且准备处理事件时被调用// handler被添加进去的回调 void handlerAdded(ChannelHandlerContext var1) throws Exception;// 是 handler被移出的后的回调void handlerRemoved(ChannelHandlerContext var1) throws Exception;/** deprecated */Deprecatedvoid exceptionCaught(ChannelHandlerContext var1, Throwable var2) throws Exception;InheritedDocumentedTarget({ElementType.TYPE})Retention(RetentionPolicy.RUNTIME)public interface Sharable {}}Netty对责任处理接口做了更细粒度的划分处理器被分成了两种一种是入栈处理器 ChannellnboundHandler, 另一种是出栈处理器ChannelOutboundHandler, 这两个接口都继承自 ChannelHandler.而所有的处理器最终都在添加在Pipeline上。所 以 添加删除责任处理器的接口的 行为在Netty的 Channelpipeline中的进行了规定 public interface ChannelPipeline extends ChannelInboundInvoker,ChannelOutboundInvoker, IterableEntryString, ChannelHandler {ChannelPipeline addFirst(String name, ChannelHandler handler);ChannelPipeline addFirst(EventExecutorGroup group, String name, ChannelHandler handler);ChannelPipeline addLast(String name, ChannelHandler handler);ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler);ChannelPipeline addBefore(String baseName, String name, ChannelHandler handler);...}在默认是实现类中将所有的Handler都串成了一个链表: public class DefaultChannelPipeline implements ChannelPipeline {static final InternalLogger logger InternalLoggerFactory.getInstance(DefaultChannelPipeline.class);final AbstractChannelHandlerContext head;final AbstractChannelHandlerContext tail;...}在 Pipeline中的任意一个节点只要我们不手动的往下传播下去,这个事件就会终止传播在当前节 点。对于入栈数据默认会传递到尾节点进行回收。如果我们不进行下一步传播事件就会终止在当前 节点。对于出栈数据把数据写会客户端也意味看事件的终止。
当然在很多安全框架中也会大量使用责任链模式,比如Spring Security. Apache Shiro都会用到 设计模式中的责任链模式,感兴趣的小伙伴可以尝试自己去研究一下。
大部分框架中无论怎么实现所有的实现都是大同小异的。其实如果我们是站在设计者这个角度看 源码的话对我们学习源码和编码内功是非常非常有益处的因为这样我们可以站在更高的角度来学 习优秀的思想而不是钻到某一个代码细节里边。我们需要对所有的设计必须有一个宏观概念这样学 习起来才更加轻松。
2.5 责任链模式的优缺点
优点
1、将请求与处理解耦
2、请求处理者(节点对象)只需关注自己感兴趣的请求进行处理即可对于不感兴趣的请求直接转 发给下一级节点对象;
3、 具备链式传递处理请求功能请求发送者无需知晓链路结构只需等待请求处理结果
4、 链路结构灵活可以通过改变链路结构动态地新增或删减责任 5、 易于扩展新的请求处理类节点符合开闭原则。
缺点
1、 责任链太长或者处理时间过长会影响整体性能
2、 如果节点对象存在循环引用时会造成死循环导致系统崩溃
