在线等，挺急的！设计模式中策略模式的类膨胀问题如何解决?

Question

最初是因为重构了别人写的代码,原来的代码中大概有近千行的if-else语句.一个是公司的标准不允许这么长的方法,另外一个也是因为自己看着难受,虽然能满足业务需求,但是作为coder来说实在是难以接受(第二个才是真正的原因,第一个只是一个让自己看起来能成熟一些的借口).由于每个if中的判断都是同一个字段.第一时间考虑是重构成策略模式,基于Spring容器,通过获取同一个接口的所有实现类,并且每个实现类中都有一个固定的返回值,并以key-value(key是实现类的固定返回值,value是Spring容器中的单例实现)的形式保存到HashMap中(享元模式),通过传入不同的参数与实现类的返回值比较,利用HaspMap获取不同的实现类以替代过多的if-else判断.但随着时间的推移,需求不断增加.最初重构的时候,实现类其实已经快30个了,现在已经达到了近80个.可以说是相当夸张了.所以想尽快解决掉这个问题.由于每个实现类的逻辑都没有共通点,所以就感觉头疼,设计模式本就是封装职责,解耦变化,把不变的装起来,变的给放开,但现在我想做的事儿更像是为了减少类实现而把变的封装到一起,不知道各位有何高招,还请赐教!感谢?之前有看到菜鸟教程中对于策略模式的描述.最后写了一句可通过混合模式解决这个问题,但是也没有具体的样例供我参考.所以就跑来发帖求助了.

Answer 1

因为不了解你的业务，所以无法判定除了策略模式外还能有什么其他办法，但楼主没有必要因为策略实现类的数量多就觉得一定不好。因为这个设计模式的目的是当编写新的策略时，不需要变更现有的类，达到这个目的就行。只要把这几十个类有序的组织起来，问题就不大。
                            

Answer 2

代码复杂度和你的需求是正相关的。策略过多导致代码膨胀的问题是无解的。（个人的观点，可以看看其他人有没有高见）策略模式重构将代码用一种更有序更易维护、扩展的方式组织起来。起码比原来的if/else好多了。