设计原则之依赖反转原则（DIP）

依赖反转原则的英文翻译是“ Dependency Inversion Principle”，缩写为 DIP。Robert Martin 在 SOLID 原则中是这样定义它的：“High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions.”。王争老师形貌是这样的：高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来相互依赖。除此之外，抽象（abstractions）不要依赖详细实现细节（details），详细实现细节（details）依赖抽象（abstractions）。
所谓高层模块和低层模块的分别，简朴来说就是，在调用链上，调用者属于高层，被调用者属于低层。
刚开始学习依赖反转，估计会问谁依赖谁？怎么反转？
首先有个问题请想想，调用者和被调用者、消费者和生产者，谁依赖谁？因为有可被调用的事物（类、模块），调用者才可以调用，生产生产物了消费者才可以消费使用，所以相信大部门人都会认为调用者依赖被调用者、消费者依赖生产者。
以消费者和生产者为例：

但实际是顾客才是上帝，让上帝依赖你，你另有生路吗？
所以生产者的产物要想被消费，需要相识消费者的需求？这个时候依赖就反转了。

需求是消费者想要的产物（抽象的产物），生产者根据这个需求去生产详细的产物。这里的需求从广义讲可以明白为协议、接口、约定、风俗习惯等。
这样明白是不是觉得依赖反转也很好明白？那为什么大部门人一开始会不明白呢？这跟很多文章的例子有关系。网上很多文章一上来就举很详细的例子。
如：

看到这样的图，潜意识里会怎么分高层模块与低层模块？
是不是像下面这样：

这样分别模块自己没有错，但是不是觉得依赖并没有反转。在寻常的开发过程中，ICar都认为是低层的代码，shopper依赖ICar，说明高层依赖低层，依赖并没有反转。这正是例子太具象，让人产生了这样的潜意识。
而实际上虽然ICar被分别到低层模块，但是ICar应该明白成顾客买车的需求的抽象，Jeep、Passat这些详细车商只是根据需求实现而已。
此原则就是告诉各人要基于接口（抽象）而非实现编程的设计思想，至于为什么基于接口，请看基于接口（抽象）而非实现编程的设计思想章节。

来源：https://blog.csdn.net/xjj1314/article/details/112008752
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！