控制反转(IoC)是一种设计模式，在这种模式下，对象通过外部框架获得其依赖项，而不是向框架请求其依赖项。

使用传统查找的伪代码示例:

class Service {
    Database database;
    init() {
        database = FrameworkSingleton.getService("database");
    }
}

使用IoC的类似代码:

class Service {
    Database database;
    init(database) {
        this.database = database;
    }
}

国际奥委会的好处是:

您不依赖于中心 框架，所以这可以改变如果 想要的。 因为对象是被创建的 以注射方式使用为佳 接口，很容易创建单元 替换依赖项的测试 模拟版本。 解耦代码。

基本上它说:

类应该依赖于抽象(例如接口，抽象类)，而不是特定的细节(实现)。

对我来说，官方文章中所描述的依赖倒置原则实际上是一种错误的尝试，它试图提高固有的可重用性较低的模块的可重用性，同时也是一种解决c++语言中的问题的方法。

c++中的问题是头文件通常包含私有字段和方法的声明。因此，如果高级c++模块包含低级模块的头文件，它将取决于该模块的实际实现细节。显然，这不是一件好事。但在今天常用的更现代的语言中，这不是一个问题。

高级模块天生就不如低级模块可重用，因为前者通常比后者更特定于应用程序/上下文。例如，实现UI屏幕的组件是最高级别的，也是非常(完全)特定于应用程序的。试图在不同的应用程序中重用这样的组件是适得其反的，只会导致过度设计。

因此，在组件a的同一级别上创建依赖于组件B(不依赖于组件a)的单独抽象，只有在组件a确实对在不同的应用程序或上下文中重用有用的情况下才能完成。如果不是这样，那么应用DIP将是糟糕的设计。

如果我们可以假定公司的“高级”员工是通过执行他们的计划来获得报酬的，并且这些计划是由许多“低级”员工的计划的综合执行来交付的，那么我们可以说，如果高级员工的计划描述以任何方式与任何低级员工的具体计划耦合在一起，那么这通常是一个糟糕的计划。

If a high level executive has a plan to "improve delivery time", and indicates that an employee in the shipping line must have coffee and do stretches each morning, then that plan is highly coupled and has low cohesion. But if the plan makes no mention of any specific employee, and in fact simply requires "an entity that can perform work is prepared to work", then the plan is loosely coupled and more cohesive: the plans do not overlap and can easily be substituted. Contractors, or robots, can easily replace the employees and the high level's plan remains unchanged.

“高级”在依赖倒置原则中意味着“更重要”。

依赖倒置原理(DIP)

它是SOLID[About]的一部分，SOLID[About]是OOD的一部分，由Bob叔叔介绍。它是关于类(层…)之间的松散耦合。类不应该依赖于具体的实现，类应该依赖于抽象/接口

问题:

//A -> B
class A {
  B b

  func foo() {
     b = B();
  }
}

解决方案:

//A -> IB <|- B
//client[A -> IB] <|- B is the Inversion 
class A {
  IB ib // An abstraction between High level module A and low level module B

  func foo() {
     ib = B()
  }
}

现在A不依赖于B(一对一)，现在A依赖于B实现的接口IB，这意味着A依赖于IB的多重实现(一对多)

[DIP vs DI vs IoC]

查看这个文档:依赖倒置原则。

它基本上是说:

高级模块不应该依赖于低级模块。两者都应该依赖于抽象。 抽象永远不应该依赖于细节。细节应该依赖于抽象。

至于为什么它很重要，简而言之:更改是有风险的，通过依赖于概念而不是实现，您减少了在调用站点更改的需求。

DIP有效地减少了不同代码段之间的耦合。其思想是，尽管有许多实现方法，比如日志记录工具，但使用它的方式应该在时间上相对稳定。如果您可以提取一个表示日志记录概念的接口，那么这个接口在时间上应该比它的实现稳定得多，并且调用站点在维护或扩展日志记录机制时受更改的影响应该小得多。

通过使实现依赖于接口，您可以在运行时选择哪个实现更适合您的特定环境。根据具体情况，这可能也很有趣。