我不想说“全部”那么极端
我的印象是漂亮的设计消除了很多 if else 多态性取代了 switch-case。今天又看了一个题目，用继承去掉if-else。
在我的理解中，设计通常意味着让人们对程序中的概念感到熟悉，以便人们可以轻松地更改/扩展程序。但有时我觉得人们对“if-else”也很方便。
是否有一些指导方针，以便有时我们应该更喜欢 OO 概念，而在其他情况下我们应该只使用“if-else”
问问题
122 次
4 回答
1
我认为我们需要区分重构复杂的 if-else 语句和用于类层次结构的 if-else 逻辑。
我们总是需要 if-else 块，你的代码仍然可以优雅地使用它们。但是像所有代码一样，它必须被维护和可读。
if-esle 块在用于检查类层次结构时并不优雅。例如：
if(object.instanceof derivedClassA) {
object.doMethod();
}
else if(object.instanceof derivedClassB) {
....
}
else if(object.instanceof baseClass) {
}
...
这可以而且应该使用 OOP 技术来处理，例如继承和多态性。但是，与任何旨在改进代码的技术一样，OOP 可能会被滥用和过度使用。我总是尝试通过使用Strategy 设计模式来避免过度使用继承，这种设计模式提倡优先HAS-A关系而不是IS-A.
于 2012-05-14T07:01:13.107 回答
0
在这种情况下可能适用的一个约定是古老的“三法则”：
http://en.wikipedia.org/wiki/Rule_of_three_(computer_programming )
于 2012-05-14T03:47:11.720 回答
0
对此有一些激烈和媚俗的看法：http ://www.antiifcampaign.com/ 。
重要的是要注意，有许多语言没有多态性，并且在许多情况下，即使语言支持运行时多态性，也不能从性能角度证明它是合理的。例如，一个 N 体问题将是使用多态性的地方，即使它会起作用。
我喜欢 SO anti-if 运动中的这个主题
于 2012-05-14T03:53:16.500 回答
0
如果别的 ...
在查看顺序代码时是最易读的。当我们嵌套或链接它们时会出现问题，因为读者通常无法遵循逻辑。
如果周五早点回家 其他如果周三喝咖啡 其他如果周六或周日呆在家里
嵌套的 if 语句更加混乱。
在这些情况下，switch 类型的语句更清晰，因为它看起来像一张表格——这又是一种读者觉得适合多项选择的风格
Switch day case 周三：喝咖啡 周五：早点回家 周六，周日：待在家里
当我们提前知道选项时，就有更好的方法来处理它。
def test(v): if v == 'a': 做某事 elif v == 'b': 做其他事
测试('a') 测试('b')
效率低下且不清楚。最好使用单独命名的方法，或者如果 v 来自外部源，则使用字典。
选择 = a：做某事 b：做其他事
选择['a']?() 选择['b']?()
最后一个例子是更少的 sudo 代码和更多的咖啡脚本。这 ？在函数调用之前意味着如果字典引用无效，则不会进行调用。
我刚刚阅读了安迪的回复。三人制无处不在——而且有充分的理由。正如我上面所讨论的，太多的信息会导致混乱。我在我的博客中讨论了三法则——尤其是在讨论分解设计时。
于 2012-05-14T04:00:33.900 回答