有时我在C#3.5中编写丑陋的if-else语句; 我知道一些不同的方法来简化表驱动开发,类层次结构,无限方法等等.问题在于,替代品的编写方式仍然不如传统丑陋的if-else语句,因为没有任何约定.
嵌套if-else的深度对于C#3.5来说是正常的吗？您期望看到哪些方法而不是嵌套if-else第一个？第二？
如果我有10个输入参数,每个参数有3个状态,我应该将函数映射到每个参数的每个状态的组合(实际上更少,因为并非所有状态都有效,但有时仍然很多).我可以将这些状态表示为哈希表键和处理程序(lambda),如果键匹配则将调用它们.
它仍然是表驱动,数据驱动的开发组合.想法和模式匹配.
我正在寻找的是延长C#这样的方法,因为这对脚本(C#3.5,而不是像脚本) http://blogs.msdn.com/ericlippert/archive/2004/02/24/79292.aspx
好问题."条件复杂性"是一种代码气味.多态性是你的朋友.
条件逻辑在其初期是无辜的,当它易于理解并包含在几行代码中时.不幸的是,它很少老化.您实现了几个新功能,突然您的条件逻辑变得复杂和广泛.[Joshua Kerevsky:重构模式]
你可以做的最简单的事情之一是避免嵌套if块学会使用Guard子句.
double getPayAmount() {
if (_isDead) return deadAmount();
if (_isSeparated) return separatedAmount();
if (_isRetired) return retiredAmount();
return normalPayAmount();
};
我发现的另一件事情很简单,它使你的代码自我记录,是整合条件.
double disabilityAmount() {
if (isNotEligableForDisability()) return 0;
// compute the disability amount
与条件表达式相关的其他有价值的重构技术包括Decompose Conditional,Replace Conditional with Visitor,Specification Pattern和Reverse Conditional.
有一些非常古老的“形式主义”试图封装评估许多可能独立变量的极其复杂的表达式，例如“决策表”：
http://en.wikipedia.org/wiki/Decision_table
但是，我将在这里加入合唱团，以支持所提到的明智使用三元运算符的想法（如果可能的话），确定最不可能的条件，如果满足这些条件，您可以通过首先排除它们来终止其余的评估，然后添加 。 .. 与此相反...尝试找出最可能的条件和状态，使您无需测试“边缘”案例即可继续进行。
米里亚姆（上图）的建议是令人着迷的，甚至是优雅的，作为“概念艺术”；我实际上打算尝试一下，试图“消除”我的怀疑，即它会导致代码更难维护。
我务实的一面说，如果没有非常具体的代码示例以及条件及其相互作用的完整描述，这里就不存在“一刀切”的答案。
我是“标志设置”的粉丝：这意味着每当我的应用程序进入一些不太常见的“模式”或“状态”时，我都会设置一个布尔标志（对于该类甚至可能是静态的）：对我来说，这简化了编写复杂的 if /然后稍后进行评估。
最好的，比尔