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

Question

穷人的DI似乎是一个很好的方法，可以测试一个不可测试的遗留代码库。 我有什么缺点吗？ 在重构遗留代码时，我从未见过这种模式。 您认为大规模重构/解耦是否可行？

Answer 1

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

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

您认为大规模重构/解耦是否可行？

当您为要重构的类编写一组单元测试时，您只能进行大规模重构。 为了能够编写这些测试，您需要DI。 如果你不能引入组合根，那么穷人的DI将是你最合适的，因为不是测试不是一种选择。 将来你可能会更进一步，重构穷人的DI，但是直到这种情况发生，我认为穷人的DI是你能得到的最好的。