unit-testing - 好的测试需要很多类，这会在什么时候降低性能？

Question

对于良好的单元测试，您应该分配一些类。

这将意味着您已经分配了测试类，但实际上不应该花费更多时间来维护它们，因为与每个类具有更多功能的较少类相比，它们会更简单并且每次更改都会受到更少的影响。

与具有更少、更胖类的应用程序相比，运行具有分配类（可能使用 DI）的应用程序是否有任何真正的性能影响？

编辑

让我澄清一下。

我不是在谈论算法，我想知道，一般来说，分配类是否会影响性能。

你认为分配的类，我在考虑每个类一个公共方法和几乎所有提取到类的私有方法。

这是非常极端的，但假设问题是什么？

Answer 1

编辑：您是在问是否有性能受到影响。这只是一个错误的问题。性能总是会受到影响，在上下文中可以忽略不计，即使没有，使用硬件而不是软件来解决性能几乎总是更便宜，即使现在时钟速度已经趋于稳定。在购买更快的硅片并不便宜的少数情况下，课程不会成为您的限制因素，这个答案的其余部分适用。

根据我的经验，大多数需要性能增强的东西都受单位粒度以外的东西的约束。在数据上使用更快的数据存储机制或索引，或者更好的内存中集合架构，或者使用字典和循环而不是嵌套循环，所有这些都可以使性能大幅提升。处理完这些问题后，如果您仍然关心性能，则剩下的选项很少，其中大多数需要非常仔细地手动优化代码，使用性能极高的语言，这通常意味着找一个执行算法核心的顶级编码器。

还有一个简单的原则要记住：提防过早的优化。

Answer 2

现在的感觉被称为“过早优化”：对解决可能永远不会发生的问题的恐惧/冲动。

加载类通常并不慢，因为所有相关代码都已经优化到死，因为每个人都使用它。

此外，如果每次测试运行类加载需要几秒钟（= 整个运行，而不是每次测试），那也没关系，因为你的测试通常运行时间更长（如果你做错了，会增加许多数量级）。

这留下了最后一个也是最糟糕的问题：维护。编写的每一行代码在维护代码时至少需要被忽略。即使忽略代码也需要付出努力。所以更少的代码总是更好。

但这里有一个下限；您只需要最少量的代码来编码您需要的所有功能。此外，试图达到所需功能的绝对最小值需要付出很多努力，因此大多数代码只能（有点）接近。

不幸的是，这还不是全部：如果你的代码写得很好，那么你就不必看它——它会工作的。因此，编写良好的代码的维护成本远低于紧凑、快速但难以理解的代码。

这意味着当代码易于理解时，代码会更便宜。这意味着将其拆分为独立的位将使其更便宜。由于OOP的缺陷，这将导致类爆炸。

不幸的是，我们的脑力是有限的。这意味着如果一个特征分布在太多地方，就很难掌握整个画面。当代码没有在正确的位置（通常不是）以及没有人可以在很长一段时间内编写完美的代码（因此质量发生变化）这一事实时，情况会变得更糟。

结论：你可以有太多或太少的类。没有办法从外面说出来。这取决于你/你的团队有多好，你的问题有多复杂，项目有多大等等。一个好的指标是你的 bug 数据库中打开的 bug 的数量和经验。

Answer 3

与具有更少、更胖类的应用程序相比，运行具有分配类（可能使用 DI）的应用程序是否有任何真正的性能影响？

高性能来自于实施有效的算法。高效的算法通常更难编码，因此需要更好的测试。使用许多类来确保良好的测试可以更轻松地编写高效算法，从而提供更好的性能。