工作场景
工作中遇到一个需求，就是对原来的作图样式做一个改造，数据什么的不需要变动，原本的代码是数据和作图耦合在一起的，所以对这块代码做一部分重构，首先把数据和作图代码抽离，本来作图就是一种与数据无关的行为。
在这个场景中，可变项是图形的展示部分，那么图形的展示，必须降低耦合性。我选择了策略模式来改写代码，认为如果遇到需求变更，那么不同的就是展示的图形，也是就是不同的样式，这里把他当做策略来做。
类图如下，比较简单，就不做介绍了。
大家很快就发现了一个问题，我的类图和很多书上的不一样，那就是client为啥和具体实现类相关。仔细对比其他人的类图，我的类图上就多了一个client，本身作为模式，是不需要client介入的，但是没有这个client那么就不能很好的模拟真实是场景。
策略模式面对需求变更的使用
如果真是是策略变了，那么就要新建一个符合情况的策略类，然后在调用的地方，把原来的地方去掉。那一个问题来了，如果你不知道策略本身，那如何让策略生效。所以才有了client对策略本身的一个依赖。加上client后就可以谈谈这个模式的优点和缺点了。
模式优缺点
策略模式的优点
很明显就是带来了逻辑上的好处，思维更清晰了。如果是没有进行抽象的时候，代码都是混在一起的，后期维护很不方便。改成这样的话，起码逻辑是比较清晰了，而且面对需求变更的时候，可以让更改的人比较容易去找到点。
策略模式的缺点
调用处必须知道每个实现类。当实现类特别多的时候，新的编码人员，需要根据接口来找到具体的实现类，然后在实现类找到自己想要的去调用，这样不大方便。
改良
就是增加一个查找表，方便编码人员对实现类的茫然不知。如果复杂的话，可以引用工厂方法。但是还是需要对照表的。
常见问题
1，context是否是必须的
这个类其实是做上下文操作的，当上下文特别简单的时候，就显示不到他的作用了，例如对策略执行完的数据处理等等，都是需要写到context的。因为需要变更还可能只是处理处理数据的方式，而不是策略本身，加上这个context符合单一原则的，当上下文处理方式变了，只要改动context的代码就行，不需要对client处理。最好是留这个类。
2，静态方法替换策略模式
很多人使用静态方法来做一些策略的操作，这样其实也能满足很多场景的，使用静态方法，实际就是替换策略方法，毕竟策略模式调用的也是方法。这样小点的场景感觉没什么特别大的问题，因为我有时候也这样用，带来的问题比较明显的就是对context的部分代码要冗余，毕竟是直接调用，然后遇到context的写法变动，改动起来就比较麻烦，在策略特别多的情况下还是使用类来控制吧。
