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

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

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

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

依赖倒置的重点是制作可重用的软件。

其思想是，两段代码不再相互依赖，而是依赖于一些抽象的接口。然后你可以在没有另一块的情况下重复使用其中的任何一块。

最常见的实现方式是通过控制反转(IoC)容器，如Java中的Spring。在这个模型中，对象的属性是通过XML配置来设置的，而不是由对象自己去寻找它们的依赖项。

想象一下这个伪代码……

public class MyClass
{
  public Service myService = ServiceLocator.service;
}

MyClass直接依赖于Service类和ServiceLocator类。如果你想在另一个应用程序中使用它，这两个都需要。现在想象一下……

public class MyClass
{
  public IService myService;
}

现在，MyClass依赖于一个单独的接口，IService接口。我们让IoC容器实际设置那个变量的值。

所以现在，MyClass可以很容易地在其他项目中重用，而不会带来其他两个类的依赖关系。

更好的是，您不必拖动MyService的依赖项，以及这些依赖项的依赖项，以及…好吧，你懂的。

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

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

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

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

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

它基本上是说:

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

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

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

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

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

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

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

使用IoC的类似代码:

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

国际奥委会的好处是:

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

依赖倒置原理(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]