大型 Switch 语句:糟糕的 OOP? [英] Large Switch statements: Bad OOP?

问题描述

我一直认为大的 switch 语句是糟糕的 OOP 设计的征兆.过去，我读过讨论这个主题的文章，他们提供了基于 OOP 的替代方法，通常基于多态来实例化正确的对象来处理这种情况.

I've always been of the opinion that large switch statements are a symptom of bad OOP design. In the past, I've read articles that discuss this topic and they have provided altnerative OOP based approaches, typically based on polymorphism to instantiate the right object to handle the case.

我现在处于一种基于来自 TCP 套接字的数据流的怪物 switch 语句的情况，其中协议基本上由换行终止命令组成，后跟数据行，后跟结束标记.命令可以是 100 个不同命令中的一个，所以我想找到一种方法来减少这个怪物 switch 语句，使其更易于管理.

I'm now in a situation that has a monsterous switch statement based on a stream of data from a TCP socket in which the protocol consists of basically newline terminated command, followed by lines of data, followed by an end marker. The command can be one of 100 different commands, so I'd like to find a way to reduce this monster switch statement to something more manageable.

我已经用谷歌搜索找到了我记得的解决方案，但遗憾的是，如今谷歌已经成为许多查询无关结果的荒地.

I've done some googling to find the solutions I recall, but sadly, Google has become a wasteland of irrelevant results for many kinds of queries these days.

这类问题有什么模式吗?关于可能的实现有什么建议吗?

Are there any patterns for this sort of problem? Any suggestions on possible implementations?

我曾想过使用字典查找，将命令文本与要实例化的对象类型相匹配.这有一个很好的优点，即只需创建一个新对象并在表中为任何新命令插入一个新命令/类型.

One thought I had was to use a dictionary lookup, matching the command text to the object type to instantiate. This has the nice advantage of merely creating a new object and inserting a new command/type in the table for any new commands.

但是，这也存在类型爆炸的问题.我现在需要 100 个新类，而且我必须找到一种方法将它们干净地连接到数据模型.一个真正的 switch 语句"真的可行吗?

However, this also has the problem of type explosion. I now need 100 new classes, plus I have to find a way to interface them cleanly to the data model. Is the "one true switch statement" really the way to go?

感谢您的想法、意见或评论.

I'd appreciate your thoughts, opinions, or comments.

推荐答案

您可能会从 中获得一些好处命令模式.

对于 OOP，如果行为变化足够小，您可以将几个类似的命令分别折叠到一个类中，以避免类完全爆炸(是的，我已经听到 OOP 大师们对此的尖叫).但是，如果系统已经是 OOP，并且 100 多个命令中的每一个都确实是独一无二的，那么只需将它们制作成独特的类，并利用继承来整合通用的东西.

For OOP, you may be able to collapse several similar commands each into a single class, if the behavior variations are small enough, to avoid a complete class explosion (yeah, I can hear the OOP gurus shrieking about that already). However, if the system is already OOP, and each of the 100+ commands is truly unique, then just make them unique classes and take advantage of inheritance to consolidate the common stuff.

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

If the system is not OOP, then I wouldn't add OOP just for this... you can easily use the Command Pattern with a simple dictionary lookup and function pointers, or even dynamically generated function calls based on the command name, depending on the language. Then you can just group logically associated functions into libraries that represent a collection of similar commands to achieve manageable separation. I don't know if there's a good term for this kind of implementation... I always think of it as a "dispatcher" style, based on the MVC-approach to handling URLs.

这篇关于大型 Switch 语句:糟糕的 OOP?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！