当前位置:正文

且特殊的处理后果比条款判断相貌要低好多中国

发布日期:2024-05-29 15:31    点击次数:181

[[321098]]中国

 中国我也不必料到打算形状

好多东谈主以为我方写的是业务代码,按照逻辑写下去,再把公用的方法抽出来复用就不错了,料到打算形状根底就没必要用,更没必要学。

一运行的技能,我亦然这样想,直到我碰到。。。

举个栗子

咱们先看一个常常的下单阻难接口。

基本逻辑,参数安全阻难,次数阻难,礼貌阻难,齐通过,复返允许下单,随心一个失败,复返对应的失败原因。

多层嵌套if写法

咱们正常多层嵌套if的写法

 

/**  * @author saier  * @date 2020/3/31 18:03  */ public class Order {     public Message interrupt1(){         return null;     }     public Message interrupt2(){         return null;     }     public Message interrupt3(){         return null;     }     public Message interrupt4(){         return null;     }     public Message interrupt5(){         return null;     }      public static void main(String[] args) {         Order order= new Order();         if(order.interrupt1().getResult() == 1){             if(order.interrupt2().getResult() == 1){                 if(order.interrupt3().getResult() == 1){                     if(order.interrupt4().getResult() == 1){                         if(order.interrupt5().getResult() == 1){                             System.out.println("success");                         }                     }                 }             }         }      } }  @Data class Message {     private int result;     private String msg; } 

特殊处理逻辑

巧合有些愚弄特殊作念逻辑,代码会浅易极少

 

/**  * @author saier  * @date 2020/3/31 18:03  */ public class Order2 {     public void interrupt1(){      }     public void interrupt2(){      }     public void interrupt3(){         //失败         throw new RuntimeException();     }     public void interrupt4(){         //失败         throw new RuntimeException();     }     public void interrupt5(){         //失败         throw new RuntimeException();     }      public static void main(String[] args) {         Order2 order2= new Order2();         try{             order2.interrupt1();             order2.interrupt2();             order2.interrupt3();             order2.interrupt4();             order2.interrupt5();             System.out.println("success");         }catch (RuntimeException e){             System.out.println("fail");         }      } } 

一运行,我就径直使用特殊来作念逻辑。但后续逻辑越来越复杂之后,也会出现一些问题。举例特殊只可复返特殊信息,不行复返更多的字段信息。

背面也钟情到,特殊作念逻辑,在阿里步调是退却的。

阿里代码步调 :

【强制】特殊不要用来作念进程限度,条款限度。

评释:特殊料到打算的初志是解决要津运行中的多样不测情况,且特殊的处理后果比条款判断相貌要低好多。

更迫切的是,代码可读性太差了,随时一个方法的特殊抛出来中国,还要斟酌代码自己的特殊。

没更好的观点,只可斟酌料到打算形状了

怎么改,会使代码的可读性高,推广性好?

在共事的指示下,倏得想起了料到打算形状!

咱们但愿达到的方针

代码莫得这样多if else嵌套,可读性高 如若新增新的阻难逻辑浅易便捷,不影响蓝本的逻辑,推广性好 不错很便捷地转化阻难逻辑章程,低耦合

包袱链形状

在这种场景下,相配稳当包袱链形状。(什么场景使用什么料到打算形状,这就需要平时有麇集,知谈多样料到打算形状的基本使用)

包袱链,顾名想义,即是用来处理干系事务包袱的一条扩充链,扩充链上有多个节点,每个节点齐有契机(条款匹配)处理苦求事务,如若某个节点处理收场就不错凭据本色业务需求传递给下一个节点不绝处理巧合复返处理完毕。

领先,缔造过滤器的详尽类

 

public abstract class AbstractFilter {      private AbstractFilter nextFilter;      /**      * 包袱链的下一个元素      */     public void setNextFilter(AbstractFilter nextFilter){         this.nextFilter = nextFilter;     }       public AbstractFilter getLastFilter(){         if(this.nextFilter != null){             return this.nextFilter.getLastFilter();         }else{             return this;         }     }      public void filter(FilterRequest filterRequest, Response response){         doFilter(filterRequest,response);         if(response.isFilterNext() && nextFilter != null){             nextFilter.filter(filterRequest,response);         }     }      /**      * 具体阻难逻辑      */     public abstract void doFilter(FilterRequest filterRequest, Response response);      /**      * 凭据阻难罢了作念处理      */     public void exec(FilterRequest filterRequest, Response response){     } } 

过滤器的末端类

 

@Component @Order(5) public class CheckParamFilter1 extends AbstractFilter {     @Override     public void doFilter(FilterRequest filterRequest, Response response) {      } }  @Component @Order(10) public class CheckParamFilter2 extends AbstractFilter {     @Override     public void doFilter(FilterRequest filterRequest, Response response) {      } } 

使用Order注解,笃定过滤器的章程,后续在spring注入的技能,会有奇效

//愚弄spring的自动注入机制 @Autowired List<AbstractFilter> abstractFilterList;  private AbstractFilter firstFilter;  //spring注入后自动扩充 @PostConstruct public void initializeChainFilter(){     //把所有调用的逻辑注入到包袱链,按照Order排序,越小优先级越高     for(int i = 0;i<abstractFilterList.size();i++){         if(i == 0){             firstFilter = abstractFilterList.get(i);         }else{             firstFilter.getLastFilter().setNextFilter(abstractFilterList.get(i));         }     } }  //径直使用 public Response exec(){     firstFilter.filter(filterRequest, response);     return response; } 

使用料到打算形状的平允

看下使用包袱链形状后,有什么平允!

新增阻难逻辑,只需要再末端一个AbstractFilter类即可 修改阻难章程,只需要修改Order注解的大小,越小,优先级越高 代码明晰,所有处理逻辑下千里到末端类中

使用料到打算形状的过错

作念到了低耦合,高推广。但也带来了一些不好的地点

逻辑更复杂,用了链式等数据结构,要堤防单例的问题,不行重叠使用 类数目激增,一个阻难器就一个类

临了小结一下

不是什么地点齐稳当使用料到打算形状,如若逻辑浅易,你硬要使用料到打算形状,只会带来结构上的复杂,全球不错按照全球的业务场景来使用。

对于作家:南山狮:理工男中国,7年互联网电商系统开辟劝诫,学问共享限制探索小白。





Powered by 🏆华体汇·体育全站app官网入口(中国)官方网站IOS安卓/通用版/手机版APP下载 @2013-2022 RSS地图 HTML地图