Testing 导致类爆炸的命令模式

似乎每当我使用命令模式时，总是会产生比不使用命令模式时多得多的类。这看起来很自然，因为我们在单独的类中一起执行相关代码块。如果我没有完成10个或12个命令子类，就不会困扰我，因为我可能会考虑一个只使用6个或7个类的小项目。为一个普通的7类项目安排19类左右的课程似乎几乎是错误的

另一件真正困扰我的事情是，测试所有这些命令子类是一件痛苦的事情。在我完成最后几个命令后，我感觉很迟钝，好像我的动作变慢了，不再敏捷了

---

这听起来熟悉吗？我做错了吗？我只是觉得在这个项目的后期我已经失去了我的敏捷性，我真的不知道如何以几天前的速度持续实施和测试

设计模式是以通用方式解决问题的通用模板。这种权衡正是你所看到的。这是因为您需要自定义通用方法。不过，就我个人而言，12个命令类似乎并不多

使用命令模式，希望命令简单（只是一个执行方法，对吗？），因此易于测试。此外，它们应该是可隔离测试的，即您应该能够轻松地测试命令，而不依赖于任何依赖项

您应该看到的好处有两个：

1） 您应该已经看到通过使用您选择的模式简化了您的特定、复杂的方法。i、 一些很快变得丑陋的东西现在应该变得更优雅

2） 由于简化的方法和测试单个组件的方便性，您的测试应该会更快

---

您是否可以使用其他模式，如复合模式，并使用良好的OO设计来避免重复代码（如果您正在重复代码…）

这看起来不像很多命令类，但我同意您的看法，如果它们占您的类的60%以上，则会有一点异味。如果项目足够复杂，值得使用命令模式，我怀疑您会发现一些类请求拆分。如果不是，可能是命令模式太过了

---

这里的其他答案对降低命令的复杂性提出了很好的建议，但我倾向于在可以找到它的地方简化（ala）。

我没有重复代码。它们是执行不同任务的非常简单的执行方法。正是大量的类困扰着我——因为我只有大约4或5个域类。@mike yeah 12个类并不多。如果它们很简单，您应该能够轻松地测试它们。我还认为，一旦模式就位，并且你习惯了它，你就会走得更快。因此，孤立地测试它们是没有意义的。在我的体系结构的这一层，它们受全套业务规则的约束。这也是一个非常令人讨厌的领域。@mike，你应该单独测试。您还应该测试使用这些命令的类too@hvgotcodes谢谢你的鼓励。这真的让我度过了过去24小时的难关。我进行了备份，恢复了未经测试的代码，计划了更多的代码，进行了TDD，并成功地使用了另一项功能。：）我害怕放弃命令模式。在这里，我解析文本输入，将其与正则表达式匹配，然后执行工作。这是一个小的工作量，但有意义的，连贯的功能。你认为放弃这个模式值得吗？我认为这听起来是使用命令模式的一个很好的理由！我会看一看你的其他课程，确保它们都有同样的意义，有凝聚力的功能，但听起来你走对了方向。我决定坚持下去，今天就完成了这个项目。结果比我昨天想象的要好——特别是当我退后一步，对这些命令执行了120个自动化测试时