testing - 穷人对遗留代码的依赖注入

Question

穷人的 DI 似乎是将可测试的代码库变成不可测试的遗留代码库的绝佳方式。有什么我忽略的缺点吗？我从未见过这种模式在重构遗留代码时大量使用。你认为大规模重构/解耦可行吗？

Answer 1

您可能已经知道，穷人的 DI 有很多缺点。例如，高级组件仍然依赖于低级组件而不是抽象。这使得替换抽象、装饰或拦截该抽象变得更加困难，而无需在整个代码库中引入彻底的更改。

尽管如此，poor man 的 DI 仍然比没有 DI 好，因为至少该类是可测试的。过去，我在遗留代码库中应用了相同的方法。我创建了一组新的类并为它们编写了单元测试。我尽量保持纯洁，并且在大多数情况下能够远离穷人的 DI，但我正在创建的顶级课程。我无法在代码库中引入 DI 框架，所以我的顶级类使用了穷人的 DI 并构建了完整的对象图。我的顶级课程由我无法控制的系统其他部分实例化的课程，所以这对我来说是一个很好的权衡。

你认为大规模重构/解耦可行吗？

只有在为要重构的类编写了一组单元测试时，才能进行大规模重构。为了能够编写这些测试，您需要 DI。如果您不能引入组合根，那么穷人的 DI 将是您的最佳选择，因为不进行测试不是一种选择。将来你也许可以更进一步，将穷人的 DI 重构出来，但在那之前，我认为穷人的 DI 是你能得到的最好的。