有没有关于控制反转或依赖注入价值的确凿数据？

Question

我读了很多关于IoC和DI的文章，但我不太相信在大多数情况下使用它们会有很大收获。

如果您正在编写需要可插拔组件的代码，那么是的，我看到了它的价值。但是如果你不是，那么我怀疑把依赖从一个类变成一个接口是否真的能给你带来任何好处，除了更多的类型。

在某些情况下，我可以看到IoC和DI在模拟方面的帮助，但是如果你没有使用模拟或测试驱动开发，那么它的价值是什么？这是YAGNI的案例吗？

Answer 1

我怀疑你会有任何关于它的硬数据，所以我将对它补充一些想法。

首先，您不使用DI (或其他可靠原则)，因为它有助于您进行TDD。反过来，你做TDD是因为它有助于你的设计--这通常意味着你会得到遵循这些原则的代码。

讨论为什么使用接口是另一回事，请参阅：https://stackoverflow.com/questions/667139/what-is-the-purpose-of-interfaces。

我假设你同意让你的类做很多不同的事情会导致混乱的代码。因此，我假设您已经在使用SRP了。

因为您有不同的类来做特定的事情，所以您需要一种方法来关联它们。如果您在类(即构造函数)中关联它们，您将获得大量使用特定版本的类的代码。这意味着对系统进行更改将是困难的。

你需要改变系统，这是软件开发的事实。您可以通知YAGNI不添加特定的额外功能，但不是因为您不需要更改系统。在我的例子中，这是非常重要的事情，因为我每周都会做冲刺。

我使用DI框架，其中的配置是通过代码完成的。使用非常小的代码配置，您可以连接许多不同的关系。因此，当您取消关于接口与具体类的讨论时，实际上是在节省输入，而不是相反。此外，对于构造函数上有一个具体类的情况，它会自动将其挂钩(我不必配置)来构建其余的关系。它还允许我控制一些对象的生命周期，特别是我可以将一个对象配置为Singleton，它总是传递一个实例。

还要注意，仅仅使用这些实践并不会带来更多的开销。第一次使用它们，是导致开销的原因(因为学习过程+在某些情况下思维方式的改变)。

归根结底:你不需要把所有的构造函数调用都放在一起才能更快。

Answer 2

从DI中获得的最大收益不一定是由于接口的使用。实际上，您不需要使用接口来实现依赖注入的有益效果。如果只有一个实现，你可以直接注入它，并且你可以混合使用类和接口。

您仍然是松散耦合的，并且相当多的开发环境可以在需要时通过几个按键来引入该接口。

关于松散耦合的价值，我不能给出确切的数据，但从我记事起，这就是教科书中的一个愿景。现在它是真的了。

当涉及到大型结构的分层构造时，DI框架还为您提供了一些非常令人惊叹的功能。与其寻找最精简的依赖注入框架，我建议你寻找一个功能齐全的框架。少并不总是多，至少在学习新的编程方法时是这样。那么你可以花更少的钱。

Answer 3

除了测试之外，松耦合也是值得的。

我曾经为一个嵌入式Java系统开发过组件，它在启动后有一个固定的对象配置(大约50个对象，大部分是不同的)。

第一个组件是没有依赖注入的遗留代码，以及到处创建的子对象。现在，对于一些修改，一些代码需要与一个对象对话，而这个对象在三个构造函数之外才可用，这种情况已经发生了好几次。因此，除了向构造函数添加另一个参数并传递它，或者甚至将其存储在一个字段中以供稍后传递之外，还能做什么呢？从长远来看，事情变得比他们已经做的更复杂了。

我从头开始开发的第二个组件，使用了依赖注入(当时并不知道)。也就是说，我有一个工厂，它构造了所有的对象，然后在需要知道的基础上注入。添加另一个依赖项很简单，只需将其添加到工厂和对象构造函数(或者添加一个setter以避免循环)。没有不相关的代码需要触摸。