在某些情况下 switch(case) 是一个很好的设计选择(除了简单性)而不是策略或类似模式......
8 回答
在测试基元值时使用开关。(即整数或字符)。
在不同类型之间进行选择时使用多态性。
示例:测试用户输入的字符是否为“a”、“b”或“c”之一是开关的工作。
测试您正在处理的对象是 Dog 还是 Cat 是多态调度的工作。
在许多语言中,如果您有更复杂的值,您可能无论如何都无法使用 Switch。
首先,简单通常是一个很好的设计选择。
我从来不理解这种对开关/案例的偏见。是的,它可以被滥用,但是,几乎所有其他编程结构也可以。
切换类型通常是错误的,可能应该由多态性代替。打开其他东西通常没问题。
一方面,可读性。
当然是。很多时候,您的开关只与您的整体逻辑的一小部分相关,并且仅仅为了这个微小的影响而创建全新的类是错误的。
例如,假设您有一个单词数据库,用户输入了另一个单词,并且您想在数据库中找到该单词,但包括可能的复数形式。你可能会写类似 (C++)
vector<string> possible_forms;
possible_forms.push_back(word);
char last_letter = word[word.size() - 1];
switch (last_letter) {
case 's':
case 'i':
case 'z':
possible_forms.push_back(word + "es");
break;
case 'y':
possible_forms.push_back(word.substr(0, word.size() - 1) + "ies");
break;
default:
possible_forms.push_back(word + "s");
}
用策略来做这件事是矫枉过正的。
通常没问题,只要你在一个地方只有一个开关。当您拥有多个(或多个)时,是时候考虑替代方案了。
可以使用开关创建“策略”。
这可能是起点,然后让多态性完成这项工作。
想到的其他需要以灵活性为代价的额外速度。有案例。
不,switch 语句可能只是简单情况下的一个不错的设计选择。
一旦你通过了一个简单的情况 switch 语句,保持更新和维护就变得非常痛苦。这是设计模式出现的部分原因。
我的观点是 switch 总是错误的:
案例的主体是代码并且是行为,因此,案例中的事物(“值”)具有行为类型,因此,多态性将是更好的选择。
这意味着值实际上是类型,例如数字 1 是在某种程度上等于 1 的所有事物的类型。剩下的就是我们将 1-ness 映射到我们特定情况的行为,并且我们对所有其他类型都有多态性(一件好事)。
这在某些语言中比其他语言更容易完成,不幸的是,大多数常用语言都非常糟糕,因此阻力最小的路径是错误的,人们最终会编写 switch 或 if 语句(同样的事情)。