N个if+else跟策略模式&&状态模式

这篇帖子讨论结果差不多了，结贴吧，讨论除了很多好的东西，非常感谢大家


  坛子里面有很多帖子，提到说怎么解决if else过来带来的判断问题，每次这个一出来，下面回帖都是策略模式 状态模式

但实际真能解决吗？

先说状态模式吧



  如图，现在有平行的三个策略，但是使用哪个策略是在context里面决定的，那么if else 有替换吗？

只不过if else 里面的东西处理被封住了，if else 什么的还是在那摆着

再说状态模式




   状态模式关键在context里面有一个保存状态的东西，然后调用request方法，下面的A，B类是不是平行的，不可替换的，他们对应不同状态，那到底什么状态，在context里面还是得判断，然后调用不同状态的handle
if else 在也没解决，只不过把需要判断的内容要你在其它地方判断好，这里直接set对应状态




个人理解：策略是处理方式有多种，都是平行的，用if else选择执行哪种
状态也有多种，不同状态对应处理不同，但不能替换不是平行的原因是由于在context调用时候，已经set它的状态了

    这只是简单运用模式，只是想说明那个if else 不是策略模式 状态模式很多时候能解决的，实际设计模式使用当然不是这么简单比如状态模式模拟工作流的时候，一个状态处理，对应状态改变，然后更加状态的改变再调用不同的状态处理

状态机不会减少if个数，
只是把对应的一组if放在一起
看起来清爽一些

一般比较通用的单分支
用表驱动法是比较常见的
Map太好用了

还有些业务可以用SQL包装达到减少代码的思路

对于用多态，一般很少第一想到。。。。
只有业务真的用多态解释的更通顺时才使用

最后可以使用大量的语法糖+已完善的软件包
来减少 显式 if for 数量
比如 各种Utils ,javautil包,common Collection包,函子包,guava包
等等等

PS：总分支数量会有升或降
但不会程指数或对数变化。
就是说业务这东西只要分析出来了
那么分支数就差不多了不会一下多出10倍或少9成。
总分支数在代码覆盖率图表上有
实际覆盖的分支数与需求设计成一定比例
0.5－4倍左右
所以总工作量的历史数据一般用这个值进行估算

对付常见的if else 工厂方法+策略模式

我来看看，帮你顶顶。

看看，正好这两天遇到if else 过多的问题

一些大粒度的if else可以用多态来代替

只有两个到三个条件的 就if 其他的 都使用map..所以俺代码里面没什么明显的判断

单独使用策略模式的确不能减少if/else，可以配合简单工厂模式，《重构》里也是这么做的。但策略模式本身已经体现了单一职责的原则：把逻辑从客户端剥离出来，使客户端的职责更清晰。

策略加工场能封装if里面的选择吗？只是if里面的执行罢了

确实是这样，但是要减少if else这个判断，结合工场模式怎么解决？工场模式不就是把选择放到工场里面了吗？实质对项目的if else并没有减少