是否有这样的例子，开关(案例)是一个好的设计选择(除了简单性)而不是战略或类似的模式…

在测试基元值时使用开关。(即整数或字符)。

在不同类型之间进行选择时，请使用多态性。

实例：测试用户输入的字符是否为"a"、"b"或"c"中的一个字符是交换机的作业。

测试你要处理的对象是狗还是猫是多态分派的工作。

在许多语言中，如果您有更复杂的值，那么您可能无论如何都不能使用switch。

首先，简单往往是一个好的设计选择。

我从来没有理解过这种对开关/外壳的偏见。是的，它可以被滥用，但是，几乎所有其他编程构造都可以。

打开类型通常是错误的，可能应该用多态性来代替。打开其他东西通常是可以的。

是的，当然。很多时候，您的开关只与整个逻辑的一个非常小的部分相关，仅仅为了这个小的影响而创建整个新类是一个错误。

例如，假设您有一个单词数据库，用户输入另一个单词，您希望在数据库中找到该单词，但包含可能的复数。你可以写一些类似的东西(C++)

用策略来做这件事太过分了。

首先，可读性。

只要你在一个地方只有一个开关，通常都可以。当你有不止一个(或多个)的时候，也应该考虑其他选择。

"战略"可以通过一个开关来创建。

这可能是起点，从那里开始让多态性完成工作。

另一个需要以灵活性为代价的额外速度。有些情况。

不，switch语句可能只是简单情况下的一个好的设计选择。

一旦您通过了一个简单的情况切换语句，就很难继续更新和维护。这就是设计模式产生的部分原因。

我的观点是，开关总是错误的：

案件的主体是代码和行为，因此，案例中的事物("价值")具有行为类型，因此，多态性将是更好的选择。

这意味着值实际上是类型，例如，数字1是在某种程度上等于1的所有类型。剩下的就是我们将1-性映射到特定情况下的行为，并且我们与所有其他类型都具有多态性(一件好事)。

这在某些语言中比其他语言更容易做到，不幸的是，大多数常用语言都相当糟糕，所以阻力最小的路径是错误的，人们最终会编写开关或if语句(同样的事情)。