除了一大堆不错的答案之外，我还想举一个我自己的小例子来说明好的和坏的做法。是的，我不是那种会扔石头的人!

比如说，你想要一个小程序通过控制台I/O将一个字符串转换成base64格式。这是一种幼稚的方法:

class Program
{
    static void Main(string[] args)
    {
        /*
         * BadEncoder: High-level class *contains* low-level I/O functionality.
         * Hence, you'll have to fiddle with BadEncoder whenever you want to change
         * the I/O mode or details. Not good. A good encoder should be I/O-agnostic --
         * problems with I/O shouldn't break the encoder!
         */
        BadEncoder.Run();            
    }
}

public static class BadEncoder
{
    public static void Run()
    {
        Console.WriteLine(Convert.ToBase64String(Encoding.UTF8.GetBytes(Console.ReadLine())));
    }
}    

DIP基本上是说高级组件不应该依赖于低级实现，根据Robert C. Martin(《清洁架构》)的说法，“级别”是指与I/O的距离。但是如何摆脱这种困境呢?简单地让中央编码器只依赖于接口，而不考虑这些接口是如何实现的:

class Program
{
    static void Main(string[] args)
    {           
        /* Demo of the Dependency Inversion Principle (= "High-level functionality
         * should not depend upon low-level implementations"): 
         * You can easily implement new I/O methods like
         * ConsoleReader, ConsoleWriter without ever touching the high-level
         * Encoder class!!!
         */            
        GoodEncoder.Run(new ConsoleReader(), new ConsoleWriter());        }
}

public static class GoodEncoder
{
    public static void Run(IReadable input, IWriteable output)
    {
        output.WriteOutput(Convert.ToBase64String(Encoding.ASCII.GetBytes(input.ReadInput())));
    }
}

public interface IReadable
{
    string ReadInput();
}

public interface IWriteable
{
    void WriteOutput(string txt);
}

public class ConsoleReader : IReadable
{
    public string ReadInput()
    {
        return Console.ReadLine();
    }
}

public class ConsoleWriter : IWriteable
{
    public void WriteOutput(string txt)
    {
        Console.WriteLine(txt);
    }
}

注意，你不需要触摸GoodEncoder来改变I/O模式——这个类对它知道的I/O接口很满意;任何IReadable和IWriteable的低级实现都不会打扰它。

这是什么?

The books Agile Software Development, Principles, Patterns, and Practices and Agile Principles, Patterns, and Practices in C# are the best resources for fully understanding the original goals and motivations behind the Dependency Inversion Principle. The article "The Dependency Inversion Principle" is also a good resource, but due to the fact that it is a condensed version of a draft which eventually made its way into the previously mentioned books, it leaves out some important discussion on the concept of a package and interface ownership which are key to distinguishing this principle from the more general advise to "program to an interface, not an implementation" found within the book Design Patterns (Gamma, et. al).

To provide a summary, the Dependency Inversion Principle is primarily about reversing the conventional direction of dependencies from "higher level" components to "lower level" components such that "lower level" components are dependent upon the interfaces owned by the "higher level" components. (Note: "higher level" component here refers to the component requiring external dependencies/services, not necessarily its conceptual position within a layered architecture.) In doing so, coupling isn't reduced so much as it is shifted from components that are theoretically less valuable to components which are theoretically more valuable.

这是通过设计其外部依赖关系用接口表示的组件来实现的，该接口的实现必须由组件的使用者提供。换句话说，定义的接口表示组件需要什么，而不是如何使用组件。“INeedSomething”，而不是“IDoSomething”)。

依赖倒置原则没有提到的是通过使用接口(例如MyService→[ILogger⇐Logger])抽象依赖关系的简单实践。虽然这将组件从依赖项的特定实现细节中解耦，但它并没有反转使用者和依赖项之间的关系(例如[MyService→IMyServiceLogger]⇐Logger。

为什么它很重要?

依赖倒置原则的重要性可以归结为一个单一的目标，即能够重用依赖于外部依赖的软件组件来实现部分功能(日志记录、验证等)。

在这个重用的总体目标中，我们可以划分出两种重用子类型:

Using a software component within multiple applications with sub-dependency implementations (e.g. You've developed a DI container and want to provide logging, but don't want to couple your container to a specific logger such that everyone that uses your container has to also use your chosen logging library). Using software components within an evolving context (e.g. You've developed business-logic components which remain the same across multiple versions of an application where the implementation details are evolving).

With the first case of reusing components across multiple applications, such as with an infrastructure library, the goal is to provide a core infrastructure need to your consumers without coupling your consumers to sub-dependencies of your own library since coupling to such dependencies requires your consumers to require the same dependencies as well. This can be problematic when consumers of your library choose to use a different library for the same infrastructure needs (e.g. NLog vs. log4net), or if they choose to use a later version of the required library which isn't backward compatible with the version required by your library.

对于重用业务逻辑组件的第二种情况(即。“高级组件”)，目标是将应用程序的核心域实现与实现细节的不断变化的需求(即更改/升级持久性库、消息传递库、加密策略等)隔离开来。理想情况下，更改应用程序的实现细节不应该破坏封装应用程序业务逻辑的组件。

注意:有些人可能反对将第二种情况描述为实际的重用，认为在单个演进应用程序中使用的业务逻辑组件等组件只代表单一用途。然而，这里的思想是，对应用程序实现细节的每次更改都呈现一个新的上下文，因此呈现一个不同的用例，尽管最终目标可以区分为隔离和可移植性。

While following the Dependency Inversion Principle in this second case can offer some benefit, it should be noted that its value as applied to modern languages such as Java and C# is much reduced, perhaps to the point of being irrelevant. As discussed earlier, the DIP involves separating implementation details into separate packages completely. In the case of an evolving application, however, simply utilizing interfaces defined in terms of the business domain will guard against needing to modify higher-level components due to changing needs of implementation detail components, even if the implementation details ultimately reside within the same package. This portion of the principle reflects aspects that were pertinent to the language in view when the principle was codified (i.e. C++) which aren't relevant to newer languages. That said, the importance of the Dependency Inversion Principle primarily lies with the development of reusable software components/libraries.

在这里可以找到关于这个原则的更长的讨论，因为它与接口的简单使用、依赖注入和分离接口模式有关。此外，关于该原则如何与动态类型语言(如JavaScript)相关的讨论可以在这里找到。

当我们设计软件应用程序时，我们可以考虑低层类——实现基本和主要操作的类(磁盘访问、网络协议……)和高层类——封装复杂逻辑的类(业务流……)。

最后一个依赖于低级类。实现这种结构的自然方法是编写低级类，一旦我们有了它们，就编写复杂的高级类。由于高级类是根据其他类定义的，这似乎是一种合乎逻辑的方法。但这不是一个灵活的设计。如果我们需要替换一个低级类，会发生什么?

依赖倒置原则指出:

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

这个原则试图“颠倒”传统的概念，即软件中的高级模块应该依赖于低级模块。在这里，高级模块拥有由低级模块实现的抽象(例如，决定接口的方法)。因此，较低级别的模块依赖于较高级别的模块。

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

我可以在上面的回答中看到很好的解释。然而，我想用简单的例子提供一些简单的解释。

依赖倒置原则允许程序员删除硬编码的依赖项，这样应用程序就变得松散耦合和可扩展。

如何实现这一点:通过抽象

没有依赖反转:

 class Student {
    private Address address;

    public Student() {
        this.address = new Address();
    }
}
class Address{
    private String perminentAddress;
    private String currentAdrress;

    public Address() {
    }
} 

在上面的代码片段中，地址对象是硬编码的。相反，如果我们可以使用依赖倒置，并通过传递构造函数或setter方法注入地址对象。让我们来看看。

使用依赖倒置:

class Student{
    private Address address;

    public Student(Address address) {
        this.address = address;
    }
    //or
    public void setAddress(Address address) {
        this.address = address;
    }
}

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

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

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

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