unit-testing - 编写通常只公开一个公共(public)方法的类是一种好习惯吗？

Question

我越是编写单元测试，我就越经常发现自己在编写越来越小的类。这些类现在是如此之小，以至于它们中的许多只有一个与接口(interface)相关联的公共(public)方法。然后测试直接针对该公共(public)方法并且相当小(有时该公共(public)方法将调用类中的内部私有(private)方法)。然后我使用 IOC 容器来管理这些轻量级类的实例化，因为它们太多了。

这是尝试以更多 TDD 方式做事的典型做法吗？我担心我现在已经将一个包含一个方法的遗留 3,000 行类重构为在频谱的另一端也难以维护的东西，因为现在实际上有大约 100 个不同的类文件。

我的所作所为是否太过分了？我试图通过这种方法遵循单一责任原则，但我可能会陷入某种贫乏的类结构中，我没有非常智能的“业务对象”。

Answer 1

这么多的小类会让我发疯。使用这种设计风格，很难弄清楚真正的工作在哪里完成。我也不喜欢拥有大量接口(interface)，每个接口(interface)都有相应的实现类。在我的书中，有很多“IWidget”和“WidgetImpl”配对是一种代码味道。

将 3,000 行的类分解成更小的部分非常棒，值得称道。但请记住目标:它是使代码更易于阅读和使用。如果你最终得到了 30 个类和接口(interface)，那么你可能只是创建了一种不同类型的怪物。现在你有一个非常复杂的类设计。将这么多类(class)记在脑海中需要大量的脑力劳动。如果有很多小类，你就会失去打开几个关键文件、挑选最重要的方法以及了解到底发生了什么的非常有用的能力。

不过，就其值(value)而言，我并没有真正支持测试驱动设计。尽早编写测试，这是明智的。但是重新组织和重组你的类设计，以便更容易进行单元测试？不，谢谢。我只会在它们具有架构意义的情况下制作接口(interface)，而不是因为我需要能够模拟一些对象以便我可以测试我的类。这就是本末倒置。