设计模式中策略模式的类膨胀问题如何解决?

Question

最初是因为重构了别人写的代码,原来的代码中大概有近千行的if-else语句.一个是公司的标准不允许这么长的方法,另外一个也是因为自己看着难受,虽然能满足业务需求,但是作为coder来说实在是难以接受(第二个才是真正的原因,第一个只是一个让自己看起来能成熟一些的借口).

由于每个if中的判断都是同一个字段.第一时间考虑是重构成策略模式,基于Spring容器,通过获取同一个接口的所有实现类,并且每个实现类中都有一个固定的返回值,并以key-value(key是实现类的固定返回值,value是Spring容器中的单例实现)的形式保存到HashMap中(享元模式),通过传入不同的参数与实现类的返回值比较,利用HaspMap获取不同的实现类以替代过多的if-else判断.

但随着时间的推移,需求不断增加.最初重构的时候,实现类其实已经快30个了,现在已经达到了近80个.
可以说是相当夸张了.所以想尽快解决掉这个问题.
由于每个实现类的逻辑都没有共通点,所以就感觉头疼,设计模式本就是封装职责,解耦变化,把不变的装起来,变的给放开,但现在我想做的事儿更像是为了减少类实现而把变的封装到一起,不知道各位有何高招,还请赐教!感谢

Answer 1

根据同一个字段的不同场景做不同处理，满足这个需求的还真只有策略模式好一点。
至于80个类是因为你有80种场景需要处理，这个不是设计模式能解决的问题。
在这个例子中，设计模式可以把你的if-else扁平化，更好的支持扩展。。
对了，超过10个的策略类，我会选择用注解+自动扫描注册到hashmap，不是手动设

Answer 2

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

Answer 3

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

Answer 4

1.你说的混合模式应该是模板方法模式 + 策略模式,这个我比较常用,但是像你说的业务场景是因为需求的增加而导致可能就没有办法了
2.你可以像DispatcherServlet中的getHandlerAdapter那样来使用策略模式,在Spring容器加载所有类的时候将所有的策略封装到一个map中,这样你在取的时候就可以根据key进行自动匹配了,这样会节省你很多代码的