依赖倒置原则(DIP)就是这么说的

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

ii)抽象永远不应该依赖于细节。细节应该依赖于抽象。

例子:

    public interface ICustomer
    {
        string GetCustomerNameById(int id);
    }

    public class Customer : ICustomer
    {
        //ctor
        public Customer(){}

        public string GetCustomerNameById(int id)
        {
            return "Dummy Customer Name";
        }
    }

    public class CustomerFactory
    {
        public static ICustomer GetCustomerData()
        {
            return new Customer();
        }
    }

    public class CustomerBLL
    {
        ICustomer _customer;
        public CustomerBLL()
        {
            _customer = CustomerFactory.GetCustomerData();
        }

        public string GetCustomerNameById(int id)
        {
            return _customer.GetCustomerNameById(id);
        }
    }

    public class Program
    {
        static void Main()
        {
            CustomerBLL customerBLL = new CustomerBLL();
            int customerId = 25;
            string customerName = customerBLL.GetCustomerNameById(customerId);


            Console.WriteLine(customerName);
            Console.ReadKey();
        }
    }

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

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

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

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

使用IoC的类似代码:

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

国际奥委会的好处是:

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

这里的其他人已经给出了很好的答案和例子。

DIP之所以重要，是因为它保证了oo原则的“松散耦合设计”。

软件中的对象不应该进入一个层次结构，其中一些对象是顶级对象，依赖于低级对象。底层对象的变化会波及到顶层对象，这使得软件非常容易发生变化。

你希望你的“顶级”对象非常稳定，不容易改变，因此你需要颠倒依赖关系。

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

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

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

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并将其传入。不需要模拟或复杂的测试脚手架。

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

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

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

没有依赖反转:

 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;
    }
}

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

它基本上是说:

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

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

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

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