设计模式专题1：设计模式在实际开发中的运用

前言：Programs are meant to be read by humans and only incidentally for computers to execute. -----Donald Ervin Knuth

场景1：

以登陆为例，比如外层需要调用一个LoginService进行登录，LoginService又需要调用其他的service来进行比如密码校验，权限校验之类的操作。时序图见下

登录时序图

问题：有需求来了，增加指纹登录类型、增加校验内容，我们的LoginService显然必须要同步改变。具体就是，逻辑内部可能需要增加很多的if else，以及一些新的外部依赖。这么做，第一，违反开闭原则，测试难度加大，需要回归整个登录功能。第二，上线后如何生产验证？发现问题怎么办？只能回滚

解决方法：

工厂方法模式

工厂方法

在设计时，增加LoginServiceFactory，按照一定的规则，生成LoginService，比如此图，LoginServiceV1和LoginServiceV2都实现LoginService接口，client调用LoginService接口即可，由LoginServiceFactory决定真正调用那个版本的login方法。

好处：增加新的LoginService实现时不用改之前的LoginService代码，降低测试难度。第二，上线后可以流控进行生产验证，发现问题，关闭即可，无需回滚。（流控逻辑写在LoginServiceFactory中）

这里只是以登陆场景为例，其他的业务场景可以参照此例自由发挥

场景2

   以下单为例，我们的下单方法OrderService中，需要去调用其他一系列的服务来进行下单校验，比如限额校验，库存校验，权限校验。所有校验都通过，才能下单成功，时序图见下

下单时序图

问题：有需求来了，需要新增一些校验，或者下单环节增加了其他的外部依赖。那么我们的OrderService是不是需要同步的增加逻辑呢？随着业务的迭代，OrderService会变的越来越臃肿。

解决方法：

责任链模式

所有的校验都实现orderFilter，形成一个orderFilterList（责任链），新增或者删除某个校验的时候，只需要新增或者删除这个实现，同时维护这个责任链即可，维护这个责任链的同时不改代码的方式有：1.使用配置文件2.初始化的时候动态的初始化责任链。

场景3:下单

以下单为例，可能每个下单都需要经过，订单校验，订单落地，真正下单，失败处理等流程。

可以使用模版方法，首先将流程固定，其次将一些共用的逻辑抽取到模板方法里面。

模板方法

场景4：策略模式

这种代码经常可以见到

```

if(a){

handleA();

}else if(b){

handleB();

}else if(c){

handleC();

}

else{

handleD();

}

```

随着时间的推移，需求的迭代，每一个分支会越来越来复杂，造成整体代码可读性变差。可以使用策略模式解决这个问题。

场景5：切面aop

这肯定用到了代理模式，不多说了

将业务流程形成文档很重要，否则遇到问题需要看代码