大型Switch语句：糟糕的OOP？

我一直认为，大型switch语句是OOP设计不良的征兆。过去，我已经阅读了讨论该主题的文章，他们提供了基于OOP的替代方法，通常基于多态来实例化处理案例的正确对象。

我现在处在一个奇怪的switch语句的情况下，该语句基于来自TCP套接字的数据流，该协议中的协议基本上由换行符终止命令，随后的数据行和结束标记组成。该命令可以是100个不同命令中的一个，因此我想找到一种方法来将此怪物切换语句减少为更易于管理的内容。

我已经进行了一些谷歌搜索来找到我记得的解决方案，但是可悲的是，如今，对于许多类型的查询，谷歌已经变成了无关紧要的结果。

有没有解决此类问题的模式？关于可能的实现有什么建议吗？

我曾经想到的是使用字典查找，将命令文本与要实例化的对象类型进行匹配。这具有仅创建一个新对象并为任何新命令在表中插入新命令/类型的优点。

但是，这也存在类型爆炸的问题。现在，我需要100个新类，此外，我还必须找到一种将它们与数据模型完全接口的方法。“一个真正的转换声明”真的可行吗？

非常感谢您的想法，意见或评论。

您可以从Command Pattern中获得一些好处。

对于OOP，如果行为变化足够小，则可以将几个类似的命令折叠到一个类中，以避免整个类爆炸（是的，我已经听说过OOP专家已经对此大喊大叫了）。但是，如果系统已经是OOP，并且100多个命令中的每一个都是真正唯一的，则只需使它们成为唯一的类并利用继承的优势来合并常用的东西。

如果系统不是OOP，那么我不会仅为此添加OOP ...您可以轻松地通过简单的字典查找和函数指针使用Command Pattern，甚至可以根据命令名称动态生成函数调用，具体取决于语言。然后，您可以将逻辑上关联的函数分组到代表相似命令集合的库中，以实现可管理的分离。我不知道这种实现是否有很好的用语……我一直认为它是一种基于MVC处理URL的“调度程序”风格。

我看到有两个switch语句是非OO设计的症状，其中enum-switch类型可以用提供抽象接口的不同实现的多种类型替换；例如，以下...

switch (eFoo)
{
case Foo.This:
  eatThis();
  break;
case Foo.That:
  eatThat();
  break;
}

switch (eFoo)
{
case Foo.This:
  drinkThis();
  break;
case Foo.That:
  drinkThat();
  break;
}

...也许应该改写为...

IAbstract
{
  void eat();
  void drink();
}

class This : IAbstract
{
  void eat() { ... }
  void drink() { ... }
}

class That : IAbstract
{
  void eat() { ... }
  void drink() { ... }
}

但是，一个switch语句不是imo的有力指示，因此该switch语句应替换为其他内容。

该命令可以是100个不同命令之一

如果您需要从100种不同的事情中完成一项，则无法避免拥有100条分支。您可以在控制流（开关，if-elseif ^ 100）或数据（从字符串到命令/工厂/策略的100个元素的映射）中对其进行编码。但是它将在那里。

您可以尝试将100向分支的结果与不需要知道该结果的事物区分开。也许只有100种不同的方法都可以。如果这会使代码变得笨拙，则无需发明不需要的对象。

我认为这是少数几个大型开关是最佳答案的情况之一，除非提出其他解决方案。

我看到了策略模式。如果我有100种不同的策略，那就这样吧。巨大的转换声明是丑陋的。所有命令都是有效的类名吗？如果是这样，只需将命令名称用作类名称，然后使用Activator.CreateInstance创建策略对象。

在谈论大型switch语句时，有两件事要想到：

1. 它违反了OCP-您可能会不断维护重要功能。
2. 您的性能可能很差：O（n）。

另一方面，映射实现可以符合OCP，并且可能会以O（1）执行。

我要说的问题不是大的switch语句，而是其中包含的代码激增以及滥用范围错误的变量。

我自己在一个项目中经历了这一点，当时越来越多的代码进入开关，直到变得难以维护。我的解决方案是在参数类上定义该类，其中包含命令的上下文（名称，参数等，在切换之前收集的内容），为每个case语句创建一个方法，然后从案例中使用参数对象调用该方法。

当然，完全的OOP命令分派器（基于诸如反射之类的魔术或Java激活之类的机制）会更漂亮，但有时您只想修复问题并完成工作；）

您可以使用字典（如果使用Java进行编码，则可以使用哈希图）（史蒂夫·麦康奈尔称之为表驱动开发）。

我认为可以改进的一种方法是使代码由数据驱动，例如，对于每个代码，您都匹配处理它的对象（函数，对象）。您还可以使用反射来映射表示对象/功能的字符串并在运行时解析它们，但是您可能需要进行一些实验以评估性能。

处理此特定问题的最佳方法：干净地进行序列化和协议操作是使用IDL并使用switch语句生成封送处理代码。因为无论您尝试使用其他哪种模式（原型工厂，命令模式等），您都需要初始化命令id /字符串和类/函数指针之间的映射，因此它的运行速度比switch语句慢，因为编译器可以对switch语句使用完美的哈希查找。

是的，我认为大写陈述是人们可以改善自己代码的一种征兆……通常可以通过实施一种更加面向对象的方法来实现。例如，如果我发现自己在switch语句中评估类的类型，那几乎总是意味着我可能可以使用泛型来消除switch语句。

您还可以在此处采用一种语言方法，并在语法中定义带有相关数据的命令。然后，您可以使用生成器工具来解析语言。我已将Irony用于该目的。另外，您可以使用解释器模式。

在我看来，目标不是建立最纯粹的OO模型，而是创建一个灵活，可扩展，可维护且功能强大的系统。

最近，我在巨大的switch语句中遇到了类似的问题，并且通过最简单的解决方案（查找表）和返回所需值的函数或方法摆脱了丑陋的开关。命令模式是很好的解决方案，但我认为有100个类不是很好。所以我有这样的事情：

switch(id)
    case 1: DoSomething(url_1) break;
    case 2: DoSomething(url_2) break;
    ..
    ..
    case 100 DoSomething(url_100) break;

我已经更改为：

string url =  GetUrl(id);  
DoSomthing(url);

GetUrl可以转到数据库并返回您要查找的URL，或者可以是内存中包含100个URL的字典。我希望这可以在替换庞大的switch语句时为任何人提供帮助。

想想Windows是如何最初在应用程序消息泵中编写的。糟透了 使用添加的更多菜单选项，应用程序将运行缓慢。随着命令搜索的结束越来越接近switch语句的底部，等待响应的时间越来越长。较长的switch语句，句点是不可接受的。我做了一个AIX守护程序作为POS命令处理程序，它可以处理256个唯一命令，甚至不知道通过TCP / IP接收到的请求流中包含什么。流的第一个字符是函数数组的索引。任何未使用的索引均设置为默认消息处理程序；登录并说再见。