什么是' Inversion'在依赖倒置中

时间:2015-01-16 07:02:15

标签: java spring

我正在学习春天。我理解依赖注入。在某些地方,我也看到它称为依赖倒置。我知道为什么它被称为注射,但其意思是"反转"?它实际上反转了哪种依赖?

3 个答案:

答案 0 :(得分:8)

好问题 - 单词inversion有点令人惊讶(因为,在应用DIP之后,较低级别的依赖模块显然不会在更高级别的调用者身上depend模块,或者 - 调用者和依赖者现在只是通过额外的抽象松散耦合了。)

引用罗伯特·C·马丁的original source

  

有人可能会质疑为什么我使用“反转”这个词。坦率地说,这是因为更多传统的软件开发方法,例如结构化分析和设计,倾向于创建软件结构,其中高级模块依赖于低级模块,并且抽象依赖于细节。实际上,这些方法的目标之一是定义子程序层次结构,该子程序层次结构描述高级模块如何调用低级模块。 ...因此,精心设计的面向对象程序的依赖结构相对于通常由传统程序方法产生的依赖结构是“反转的”。

在阅读Uncle Bob关于DIP的论文时要注意的一点是,C ++没有(和at time of writing, still doesn't)具有接口,因此在C ++中实现这种抽象通常是通过抽象来实现的。 / pure virtual base class,而在Java或C#中,放松耦合的抽象通常是通过从依赖项中抽象接口,并将更高级别的模块耦合到接口来解耦。

修改 只是为了澄清:

  

"在某些地方我也看到它被称为依赖倒置"

请注意Dependency Injection (DI)是实现依赖性倒置原则(DIP)的可能实现之一 - the "D" in SOLID design principles,因此DIDIP 不< / em>完全可以互换。

其他DIP实现包括Service locator pattern(现在often regarded作为反模式);和Plugin

答案 1 :(得分:3)

<强>倒置 - 将依赖关系管理从应用程序转换为容器(例如Spring)。

依赖注入:

如何直接将对象注入客户类,而不是编写工厂模式。因此,让客户类引用接口,我们应该能够将具体类型注入到客户类中。有了这个,客户类不需要使用new关键字,并且与具体类完全分离。

enter image description here

那么控制反转(IoC)是什么?

在传统编程中,业务逻辑的由静态分配给彼此的对象确定。使用控制反转 flow 依赖于由汇编程序实例化的对象图,并且可以通过抽象定义的对象交互来实现。 绑定过程是通过依赖注入实现的,尽管有些人认为使用服务定位器也会提供控制反转。

作为设计指南的控制反转有以下目的:

  • 某个任务的执行脱离了 实施
  • 每个模块都可以专注于它的设计目标。
  • 模块不会假设其他系统所依赖的内容 他们的合同。
  • 更换模块对其他模块没有任何副作用。

有关详细信息,请查看:

Design Pattern IOC and DI

Design pattern – Inversion of control and Dependency injection

A Practical Introduction to Inversion of Control

Inversion of control (IoC) and dependency injection (DI) patterns in spring framework and related interview questions

答案 2 :(得分:0)

据我所知,“反向”一词的使用取决于这样一个事实,即接口被认为是比依赖它的服务更高级别的抽象。 被颠倒的是抽象依赖的方向:您的服务现在依赖于更高级别的事物,而不是依赖于较低级别的事物。

让我们考虑一个简化的例子。

  • 在“坏”应用程序中,FooService 依赖于 BarDatabase:我们的服务依赖于数据库实现。值得注意的是,我们的服务依赖于较低级别的“事物”
  • 在“好的”应用程序中,FooService 依赖于 DatabaseInterface,而 BarDatabase 又由 FooService 实现。由于接口被认为是比服务更高级的抽象,我们的服务现在依赖于更高级别的“事物”

现在,从某种意义上说,依赖的方向性没有改变。实际上,BarDatabase 仍然间接依赖于 BarDatabase。值得强调的是,当我们说我们已经颠倒了依赖关系时,并不是说 FooService 现在以某种方式依赖于 https://discord.com/api/v8/invites/${code}

我们的意思是,我们的服务现在依赖于更高层的东西,而不是依赖于抽象层次较低的东西。我们已经“反转”了我们的服务需要攀爬以获得其依赖项的方向。

关于为什么这是一件好事,我将遵循广泛可用的极好的解释,但直觉是依赖比你自己更抽象的事物会让你与外部事物的耦合不那么紧密,这反过来又与封装和关注点分离等好东西密切相关。

参考文献:What inverts in the dependency inversion principle?