设计模式 -- 策略模式
场景 在有多种算法, 计算策略, 甚至业务流程以一种可相互替换的场景出现时. 就可以考虑该设计模式. 比如: 地图导航的出行路线计算, 商品购买的捆绑促销方式等. 分析 优点: 将具体的策略与调用策略的流程代码解耦, 修改策略代码时候可以仅修改策略对象 在不同策略之间划清界限 增加单独策略的可测试性 缺点: 后续变更有一定束缚性 ( 限制在抽象接口中 ) . 若需要打破策略的抽象接口, 就会造成较大的改动 会带来的问题: 可能将原先一个流程代码, 拆分成了多分. 如果代码结构没有组织好, 想要大局把握可能比较费力 总结: 在流程算法策略有多个 ( 如果只有一个就没有必要抽象了, 一梭子写完就行 ), 且各个策略都有一定复杂性 ( 只是简单几个 if 的也略了吧 ) 的场景下. 就可以使用 ( 接口的签名可以写的比较松一点, 传递和返回较高层级的数据对象 ). 实现流程 主要的思想, 我觉得还是 面向接口编程 分析要拆分的算法或者策略, 将主流程和策略部分, 提取抽象成一个通用接口(interface) 将算法或策略剥离成独立的策略对象, 并实现上述抽象接口 主流程代码根据业务逻辑, 初始化策略对象, 将需要的策略"插入"(plugin)流程, 调用, 获取结果, ok. 参考 refactoringguru - strategy