是否有关于控制反转或依赖注入值的硬数据?

时间:2009-03-20 17:31:03

标签: dependency-injection inversion-of-control yagni

我已经阅读了很多关于IoC和DI的内容,但我并不确信在大多数情况下使用它们会获得很多收益。

如果您正在编写需要可插拔组件的代码,那么是的,我看到了这个值。但是,如果你不是,那么我怀疑将一个依赖从一个类更改为一个接口是否真的让你获得了任何东西,而不是更多的输入。

在某些情况下,我可以看到IoC和DI在哪里可以帮助进行模拟,但是如果你没有使用Mocking或TDD,那么它的价值是什么?这是YAGNI的案例吗?

3 个答案:

答案 0 :(得分:2)

我怀疑你会有任何硬数据,所以我会加上一些想法。

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

讨论使用接口的原因是另一回​​事,请参阅:https://stackoverflow.com/questions/667139/what-is-the-purpose-of-interfaces

我会假设您同意让您的课程执行许多不同的操作会导致代码混乱。因此,我假设你已经开始参加SRP了。

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

您将需要更改系统,这是软件开发的一个事实。您可以致电YAGNI,不要添加特定的额外功能,但不能在此之前就不需要更改系统。在我的情况下,这是非常重要的,因为我每周冲刺。

我使用DI框架,通过代码完成配置。使用非常小的代码配置,您可以连接许多不同的关系。所以,当你拿走关于接口与具体类的讨论时,你实际上是在保存输入,而不是相反。此外,对于构造函数中的具体类,它会自动挂钩(我不必配置)构建其余的关系。它还允许我控制一些对象的生命周期,特别是我可以将对象配置为Singleton并且它始终处理单个实例。

另请注意,仅使用这些做法并不会增加开销。第一次使用它们是导致开销的原因(因为学习过程+在某些情况下会改变思维模式)。

结论:你不需要把所有这些构造函数调用放在一起就能更快。

答案 1 :(得分:1)

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

你仍然会松散耦合,而且在很多开发环境中你可以根据需要用几个按键引入该接口。

关于松耦合价值的硬数据我无法给出,但只要我记得,它就是教科书中的一个愿景。现在这是真的。

DI框架在大型结构的分层构建方面也为您提供了一些非常了不起的功能。而不是寻找最精简的DI框架,我建议你寻找一个功能齐全的。少了总是更多,至少在学习新的编程方式时。 然后你可以少花钱。

答案 2 :(得分:0)

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

我参与了嵌入式Java系统的组件,它在启动后具有固定的对象配置(大约50个不同的对象)。

第一个组件是没有依赖注入的遗留代码,以及在整个地方创建的子对象。现在它发生了几次,为了进行一些修改,一些代码需要与一个只有三个构造函数可用的对象进行对话。那么你可以做什么,只是在构造函数中添加另一个参数并传递它,甚至将它存储在一个字段中以便以后传递它。从长远来看,事情变得比以前更加纠结。

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