依赖倒置:依赖抽象，而不是具体。

控制反转:主要与抽象，以及主要如何成为系统的粘合剂。

以下是一些关于这方面的好文章:

https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/

https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/

https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/

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

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

依赖倒置原则指出:

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

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

依赖倒置原则的一个更清晰的表述方式是:

封装复杂业务逻辑的模块不应该直接依赖于封装业务逻辑的其他模块。相反，它们应该只依赖于简单数据的接口。

也就是说，不是像人们通常做的那样实现你的类逻辑:

class Dependency { ... }
class Logic {
    private Dependency dep;
    int doSomething() {
        // Business logic using dep here
    }
}

你应该这样做:

class Dependency { ... }
interface Data { ... }
class DataFromDependency implements Data {
    private Dependency dep;
    ...
}
class Logic {
    int doSomething(Data data) {
        // compute something with data
    }
}

Data和DataFromDependency应该与Logic在同一个模块中，而不是与Dependency在一起。

为什么要这么做?

这两个业务逻辑模块现在已解耦。当Dependency改变时，你不需要改变Logic。 理解Logic所做的是一个简单得多的任务:它只对看起来像ADT的东西起作用。 现在可以更容易地检验逻辑。现在，您可以直接实例化假数据Data并将其传入。不需要模拟或复杂的测试脚手架。

基本上它说:

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

依赖倒置的良好应用在应用程序的整个体系结构层面上提供了灵活性和稳定性。它将允许您的应用程序更安全、更稳定地发展。

传统分层建筑

传统上，分层架构UI依赖于业务层，而业务层又依赖于数据访问层。

您必须了解层、包或库。让我们看看代码是怎样的。

我们将有一个用于数据访问层的库或包。

// DataAccessLayer.dll
public class ProductDAO {

}

以及依赖于数据访问层的另一个库或包层业务逻辑。

// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO { 
    private ProductDAO productDAO;
}

带有依赖倒置的分层体系结构

依赖倒置表明:

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

抽象不应该依赖于细节。细节应该依赖于抽象。

什么是高级模块和低级模块?思考模块，如库或包，高级模块将是那些传统上具有依赖关系的模块，而它们所依赖的低级模块。

换句话说，模块高层是调用操作的地方，而模块低层是执行操作的地方。

从这一原则可以得出一个合理的结论，即具象之间不应存在依赖关系，而必须对抽象存在依赖关系。但根据我们所采取的方法，我们可能会误用投资依赖依赖，而是一种抽象。

假设我们对代码进行如下调整:

我们将为定义抽象的数据访问层提供一个库或包。

// DataAccessLayer.dll
public interface IProductDAO
public class ProductDAO : IProductDAO{

}

以及依赖于数据访问层的另一个库或包层业务逻辑。

// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO { 
    private IProductDAO productDAO;
}

尽管我们依赖于抽象，但业务和数据访问之间的依赖关系保持不变。

要获得依赖项反转，持久性接口必须定义在高级逻辑或域所在的模块或包中，而不是定义在低级模块中。

首先定义什么是领域层，其通信的抽象是定义持久化。

// Domain.dll
public interface IProductRepository;

using DataAccessLayer;
public class ProductBO { 
    private IProductRepository productRepository;
}

在持久化层依赖于域之后，如果定义了依赖项，就可以进行反转。

// Persistence.dll
public class ProductDAO : IProductRepository{

}

(来源:xurxodev.com)

深化原则

重要的是要吸收好概念，深化目的和效益。如果我们机械地停留在学习典型案例存储库中，我们将无法确定在哪里可以应用依赖原则。

但是为什么要反转依赖关系呢?除了具体的例子，主要目标是什么?

这通常允许最稳定的东西，不依赖于不太稳定的东西，更频繁地变化。

持久化类型的更改(访问相同数据库的数据库或技术)比设计用于与持久化通信的域逻辑或操作更容易。因此，这种依赖是相反的，因为如果发生这种更改，则更容易更改持久性。这样我们就不需要改变定义域了。域层是所有层中最稳定的，这就是为什么它不应该依赖于任何东西。

但不只是这个存储库示例。有许多应用此原则的场景，并且有基于此原则的架构。

体系结构

在某些架构中，依赖倒置是其定义的关键。在所有的域中，它是最重要的，它是用来指示域和其他被定义的包或库之间的通信协议的抽象。

干净的建筑

在Clean体系结构中，域位于中心，如果您查看指示依赖关系的箭头方向，就可以清楚地看到哪些是最重要和最稳定的层。外层被认为是不稳定的工具，因此避免依赖它们。

(来源:8 thlight.com)

六角结构

这与六边形体系结构发生的情况相同，其中域也位于中心部分，端口是从多米诺骨牌向外通信的抽象。这里很明显，域是最稳定的，传统的依赖关系是颠倒的。

(来源:pragprog.com)

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

比如说，你想要一个小程序通过控制台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的低级实现都不会打扰它。