背景
假设我们有个controller会根据入参的不同，做出不同的判断，我们有时会使用if-else的方式去做处理。当业务越来越多，代码越滚越大时，分支会变得很多，代码读起来相当的“脏乱差”。往往这些业务都会有很多相同之处，这时候就可以使用设计模式对代码进行重构，变得更加整洁和可拓展。
场景
最近对接一些第三方平台，应合作方要求这些平台是需要有独立的业务逻辑的。本人把它们（之前对接过的，现在又接进来其他平台）的总业务逻辑抽离出来。无非就以下几块。
image.png
每个模块都有自己不同的逻辑算法，于是我选择了策略模式。
策略模式：看过一句话总结策略模式，就是“条条大路通罗马”。本人举个例子，想象学生的高中生涯，他们的学习策略是不同，但是却要一起参加高考，产生一份不同的高考分数。按照laravel学院里的一句话是“让算法的变化独立于使用算法的客户”。
本人是这样设计的
image.png
如上图，每个平台必经这几个方法，如获取订单和请求对方api，但是他们之间的同一个模块，却有不同的逻辑，如a平台是需要这几个参数加盐做握手时的标识，b平台却不需要。这时本人就可以实现interface，得到他们的“周期模板”，再跟进不同的逻辑，完善各自的“模板”。最终都是返回自己公司标准化的状态给前端页面。
调用时，先根据不同入参判断不同平台，创建不同的class，class是实现了interface的。context一个持有一个对象element，这时element是interface型的，通过构造器设置时，才知道调用哪个策略。
坑
这个业务逻辑是在java实现的，java不像php那样是弱类型的，参数需要严格的数据类型，但是不同的传入的参数不一定一样，十分不灵活，是不是这里不适合用策略模式呢？
于是上网问了一下其他人，有位朋友说，应该把每个行为拆分的根据细致。
于是我总结了以下几点：
-
尽可能拆分行为，即一个模块只干一件事情（这里只得模块是上图的orderInfo()之类的方法）；
-
模块之间最好不互相影响，尽量避免a模块的返回值，作为b模块的入参（当业务量大时，分支多，不确保a模块返回的数据结构都合适b模块）。
-
多个类如果大同小异的话，可以同时继承一个父类来减少重复代码。
优点
-
代码会整洁很多，可读性会高很多，避免所谓的“硬编码”。
-
更加易于维护，拓展起来及其方便。
-
比较合适团队开发，避免git提交冲突（即使冲突也可能冲突一个controller吧哈哈）。
现在想想，好像php的laravel框架中的队列，也是使用这个思想的。
网友评论