似乎每当我使用命令模式时，它总是会导致比我不使用它时要多得多的类。这看起来很自然，因为我们在不同的类中一起执行相关代码块。如果我没有完成 10 或 12 个 Command 子类，我可能会认为这是一个仅使用 6 或 7 个类的小项目，这不会让我感到那么困扰。一个普通的 7 节课项目有 19 节左右的课似乎几乎是错误的。
另一件真正困扰我的事情是测试所有这些 Command 子类是一件很痛苦的事情。执行最后几个命令后，我感觉迟钝，好像我的动作变慢了，不再敏捷。
这听起来很熟悉吗？我做错了吗？只是觉得在这个项目后期失去了敏捷性，真不知道如何以前几天的速度不断的实施和测试。
【问题讨论】：
标签： testing agile command-pattern
设计模式是以通用方式解决问题的通用模板。权衡正是您所看到的。发生这种情况是因为您需要自定义通用方法。不过，就我个人而言，12 个命令类对我来说似乎并不多。
使用命令模式，希望命令很简单（只是一个执行方法，对吗？），因此易于测试。此外，它们应该是可单独测试的，即您应该能够轻松地测试命令，而几乎没有依赖关系。
您应该看到的好处有两个：
1) 您应该已经看到使用您选择的模式简化了您的特定、复杂的方法。即快速变得丑陋的东西现在应该更优雅。
2) 由于简化的方法和易于测试您的各个组件，您应该会更快。
您能否利用其他模式，例如复合模式，并使用良好的 OO 设计来避免重复代码（如果您正在重复代码......）？
【讨论】：
这看起来不像很多命令类，但我同意你的观点，如果它们占你类的 60% 以上，它就会有点味道。如果项目足够复杂，值得使用命令模式，我怀疑您会发现一些类要求拆分。如果不是，那么命令模式可能是矫枉过正。
这里的其他答案对降低命令的复杂性有很好的建议，但我更喜欢在我能找到它的地方简单（ala bowling game）。
【讨论】：