我们分析事物是使用if else，但是表达时，最好不这样用，就象我们心里想的，和写成文章的，不是同一种方式，文章讲究技巧，说话更讲究技巧。
如果说IF ELSE是一种分类思维，那么OO面向对象属于分类思维的一种具体实现，把你分类包装成对象封装好，划定好彼此界限，然后运行时，以IF ELSE方式运行。
什么叫IF ELSE方式运行呢？就是用AOP动态拦截插拔等概念运行，DCI架构也属于这种。
所以，我们已经知道，如果说IF ELSE是人的朴素思维的话，那么面向对象思维就是软件人员的专业思维了。
所以，设计时先“分”，“分”好的代码出来后，然后我们再将这些碎片代码在运行时刻“合”起来。这也是编译型语言的一个好处，能够做到“分合”泾渭分明，也是scala比较受欢迎的原因，相反脚本语言如Ruby on Rails等就不明显了。
当一个类的内部有2个以及2个以上的操作的实现包含了相同的条件结构时，可以考虑使用策略或状态模式进行重构，重构的结果，这个类中的这些操作在界面保持不变的前提下，实现变得简洁了，消除了庞大的条件结构，代价是可能要增加若干个策略类或状态类。
这个代价的付出是否值得？看情景而定。从OCP原则看，
1）修改时，修改一个策略类或状态，比同时在多个庞大的条件结构中修改语句，更轻松一些。
2）扩展时，添加一个策略类或状态，比同时在多个庞大的条件结构中添加语句，更轻松一些。
但是，该类中庞大的条件结构只出现一次，那么在修改与扩展时，使用模式比使用条件语句并没有什么优势，相反，使用条件语句可以减少若干个策略类或状态类。此时，不妨使用原始的条件语句，更直观一些。
正如DCI消除多重继承，State和Strategy可以消除多重条件语句，但“消除”多重继承或多重条件语句，只是使用DCI或State/Strategy Pattern带来效果或副作用，应该还不是DCI和State和Strategy最直接的目标：使代码更清晰，更容易理解和看懂，同时也更容易修改和扩展。
比如当一个对象可以视为一个“状态机”时，使用状态模式，比使用条件语句进行判断要自然、直观得多。代码中出现的“多重继承”或“多重条件语句”可以作为一种“信号”，提醒我们，这代码可能需要重构。对，只是“可能”而已，你可能还要判断重构的代价是否值得付出。