依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程。
依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。
在实际的互联网开发中，实现往往具备善变性,但抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以实现为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而实现是指具体的实现类,golang中直观的参考为:interface和struct的关系。 使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。
依赖、倒置原则的作用
依赖倒置原则的主要作用如下。
- 依赖倒置原则可以降低类间的耦合性。
- 依赖倒置原则可以提高系统的稳定性。
- 依赖倒置原则可以减少并行开发引起的风险。
- 依赖倒置原则可以提高代码的可读性和可维护性。
依赖倒置原则的实现方法
依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。
- 每个类尽量提供接口或抽象类，或者两者都具备。
- 变量的声明类型尽量是接口或者是抽象类。
- 任何类都不应该从具体类派生。
- 使用继承时尽量遵循里氏替换原则。
下面以“MQ”为例来说明依赖倒置原则的应用。
【例1】依赖倒置原则在“消息队列底层开发”中的应用。
分析：本案例是基于如何实现一款自己的消息队列为触发点设计,众所周知,消息队列在现代的互联网环境下,应用甚广,从业务需求到流量削峰再到系统解耦都有其身影,但每款消息队列都有自己的优势和劣势,那么,如何针对自己的业务场景构建消息队列来符合多样性需求,而又不会因为标准不统一达不到兼容,就需要这方面的原则：
type MQInter interface{
// mq的标准实现方法
......
Load()error
DumpData()error
......
}
type Kafka struct{
}
type RabbitMq struct{
}
func(k *Kafka)Load()error{
}
func(k *Kafka)DumpData()error{
}
.......
总结:文中可能有描述不详细或者不准确的地方,请批评指正.