巧用策略模式完美应付产品四次需求变更，也吵了四次｜2021 年中总结

前言

• 设计模式大家应该很熟悉了，使用最多的应该就是工厂模式。关于工厂模式有简单工厂、懒汉工厂、饿汉工厂等等形式，今天我们结合项目场景来总结下策略模式

项目需求

• 上面是我们需求效果图！我们需要针对个人对本年度指标完成情况进行一次统计。
• 比如上面test用户在xxx年份中有5个指标考核。每个指标考核维度不一样，对于指标1考核目标是一天施工一次，然后对一个月进行汇总考核有点类似于上班打卡的形式。而他打卡的方式就是后方的施工按钮。对于指标1他只需要每天点击施工填写响应的数据即可！关于施工后填写数据就是一份表单数据这个是非常简单的。
• 包括后面1月1次、1季度1次、半年1次、1年1次这些考核频率都是同样的操作。这份报表统计应该也很容易没啥难点。我们只需要在生成的时候按照月份查找施工记录是否符合当前频率要求！

• 在项目中对频率进行判断。不同的频率我们做不一样的逻辑就完事了。这个可以说是初级程序！！！这样完全没有考虑到语言或者说设计模式。这种思路实现完全没有问题但是没有考虑到后续的扩展性！
• 首先代码会变得很长不利于他人阅读理解。其次是没有做到相互隔离如果其中一个分支出现问题需要进行修改这时候对其他的分支实际上是一次污染，因为他们都在一起，因为修改某个分支从而导致其他分支异常的情况是经常出现的。这种做法也是我之前最喜欢的方式—不知道已设计模式的角度考虑问题

瓶颈突破

• 成长是一条艰辛的道路，但是对于别人来说可能就是那么一瞬间！初级成长成中级程序员我们需要多少努力只有经历之后才知道但是对别人来说可能会认为是一次代码的事情！今天我就抛弃到传统的流水账形式开发，结合项目实战运用起设计模式。
• 经过仔细分析了之后觉得设计模式中的策略模式很是适合该需求。我们可以将频率抽象成策略 ，我们先来看看下面我的图示

• 首先将策略进行抽象成AbstrachTimeStrategy 该类主要责任就是对数据进行分析，接收两个参数分别是Map , bean 。前者是用户月份详情数据，后者是根据频率相关的解析数据。在每个策略中针对单一的场景进行具体分析，每个类具有了单一的职责这样将他们进行分离，比如说上面PerHalfSomeTimesStrategy出现的bug那么我们只需要对他进行修复，其他的策略是不会受影响的。
• 这是从宏观层面进行相互隔离。我们进入到每个策略中也是很简单了。每个策略我们只需要定制化的考虑具体的场景。比如PerDaySomeTimesStrategy策略对应的一天N次的频率。我们在里面只需要获取到指定月份的施工记录并对这些记录按天分组，最终看看每天的完成情况是否满足我们N次的要求就可以了。而不需要去考虑季度、年的频率问题
• 运用策略模式还有一个好处是我们可以随意的装配！如果现在我们的需求是多个频率只需要满足其中一个就可以了。那么我们只需要将多个频率对应的策略进行分析下就可以得出结论！如果是之前流水账形式的开发的话我们肯定是需要将代码进行重构下！说的好听的是重构，难听的就个话其词了。
• 当然除了策略以外，我们还需要一个工厂类。这个工厂类是做啥子用的呢？因为策略本身只需要考虑策略的场景。至于谁去组装这些策略那就是我们的工厂的活了。

策略组装

• 首相该工厂提供了注册器和获取对应策略的两个入口。另外注册器内部是将具体策略已别名的方式注册到内部的一个map中。为了方便我直接在工厂中添加了目前我们需求确定的策略。后续如果需求变动我就不在对工厂进行修改而是直接通过注册器向内部进行注册新的策略。

static {
    strategyMap.put("month", new PerMonthSomeTimesStrategy());
    strategyMap.put("halfMonth", new PerHalfMonthSomeTimesStrategy());
    strategyMap.put("year", new PerYearSomeTimesStrategy());
    strategyMap.put("day", new PerDaySomeTimesStrategy());
    strategyMap.put("squash", new PerSquarshSomeTimesStrategy());
    strategyMap.put("halfyear", new PerHalfYearSomeTimesStrategy());
} 

• 上述就是我们系统内部确定的6中策略。剩下的就是我们在系统需要借助策略分析的时候通过工厂的获取策略器进行分析

TimeStrategy strategy = ContextTimeStrategyFactory.getInstance().getStrategy(cycle.getCycleName()); 

• 这样子的代码看起来真的很舒服！就算是其他人来阅读也很容易理解。而且还用担心其他接手的XD改出问题！想一想当我将内置的功能如果进行maven进行分模块开发那么其他人不论怎么修改都不会影响到我们已有的6中策略了。设计模式真的是我们程序的救星啊！

需求变更