|
lqtcdc: 自从看了论坛里的那篇文章，'你还在使用if else 吗’，感触太深了，一方面我觉得，作者说的的确很有道理，原来大量使用if else 是使用了面向过程的思维方式。 原来我使用java面向对象语言却一直使用面向过程的思维方式。更牛逼的是，原来我一直没有觉察到... 难道我中毒已深，无法自拔了吗。 然后我对现实的系统和自己的思维方式剖析了一番，发现了一个问题，或者说得到一个结论吧。不管面向对象还是面向过程吧，不要谈在思维方式上谁更先进，其实这个东西还真不好说，因为经过我深入的研究，其实这两个思维方式都可以模拟表达现实世界的一些规则和秩序。面向过程的思维注重横向的，纵向的，仿佛是一个平面结构，在我们的神经网里容易组织出这样子的一个结构，因此面向过程的思维还是很适合一些逻辑的业务思考的。面向对象的思维，则像是一个立体的思维范式，我表象看到的是个物体，物体里有神马东东，需要进入观摩对象深入了解。正因为如此，面向对象的思维很适合探索类，发散类的业务思考。我不懂这个对象不要紧，我懂它我关心的一部分就可以了，至于其他的我不想懂，也没啥必要去弄懂，这个思维应该就类似面向对象了。如果说面向过程类似于数学里的代数的话，那么面向对象则类似于几何了，在本质里是有共同点的。再谈if esle ，不管是面向对象还是面向过程这个语句的使用率觉得可以排上名次，if esle 逻辑判断，很大程度上提高了系统的拓展度，简化了程序的开发。有牛逼的人说，世界上最难的事情就是做决定了。这个if esle 就帮我们做决定了，以不变应万变，极其聪明的策略。再者在实际的开发应用中，如果你要在一个一个电信或者银行的系统增加新的功能，哈哈，你不要告诉我用面向对象的方法，不然会死的很惨的。最好的方法，还是if esle 。所以，尽管看了那个文章，我觉得文章写的很好，也很扯淡，觉得if esle应该用，就不要客气的用，管它面向对象啥的，如果系统不行了，需要再次开发，OK，我不用if else 了，哈哈。 jdon007： 从面向过程（也可称为面向变量）与面向对象（也可称为面向消息）的方法论进行比较上面提到的情景也许是一种思路。这里，我提供另一种思路，从代码的可读性、可修改和可扩展进行分析。
当一个类的内部有2个以及2个以上的操作的实现包含了相同的条件结构时，可以考虑使用策略或状态模式进行重构，重构的结果，这个类中的这些操作在界面保持不变的前提下，实现变得简洁了，消除了庞大的条件结构，代价是可能要增加若干个策略类或状态类。 这个代价的付出是否值得？看情景而定。从OCP原则看， 1）修改时，修改一个策略类或状态，比同时在多个庞大的条件结构中修改语句，更轻松一些。 2）扩展时，添加一个策略类或状态，比同时在多个庞大的条件结构中添加语句，更轻松一些。 但是，该类中庞大的条件结构只出现一次，那么在修改与扩展时，使用模式比使用条件语句并没有什么优势，相反，使用条件语句可以减少若干个策略类或状态类。此时，不妨使用原始的条件语句，更直观一些。 正如DCI消除多重继承，State和Strategy可以消除多重条件语句，但“消除”多重继承或多重条件语句，只是使用DCI或State/Strategy Pattern带来效果或副作用，应该还不是DCI和State和Strategy最直接的目标：使代码更清晰，更容易理解和看懂，同时也更容易修改和扩展。 比如当一个对象可以视为一个“状态机”时，使用状态模式，比使用条件语句进行判断要自然、直观得多。代码中出现的“多重继承”或“多重条件语句”可以作为一种“信号”，提醒我们，这代码可能需要重构。对，只是“可能”而已，你可能还要判断重构的代价是否值得付出。 |
|
|
