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

Question

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

Answer 1

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

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

Do you think it s feasible for large scale refactoring / decoupling?

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