在软件设计、编码过程中有几个基本原则即SOLID原则，学习理解能够帮忙我们写出更健壮的代码。SOLID是五个基本原则的首字母。这五个原则如下：
Single responsibility
Open–closed
Liskov substitution
Interface segregation
Dependency inversion
此篇来学习一下依赖反转（倒置）原则（Dependency Inversion Principle）
定义如下：
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
即：
A、高层次的模块不要依赖于低层次的模块，都应该依赖于抽象（接口）。
B、抽象（接口）不应该依赖于具体，而具体要依赖于抽象。
我们来具体理解一下哈，比如说，码农小明穿一件毛衣，可能是圆领的也可能是鸡心领的，可能是蓝色的，也可能是红色的。
interface Coder {void wearSweater(Sweater sweater);}class XiaoMing implements Coder{@Overridepublic void wearSweater(Sweater sweater) {}}interface Sweater {}class TneckSweater implements Sweater {}
然后我们再看看client代码是怎么写的：
Coder xiaoming = new XiaoMing();Sweater tneckSweater = new TneckSweater();xiaoming.wearSweater(tneckSweater);
我们假设项目组Coder有小明、大龙、老张等6个，他们有的喜欢看韩剧，有的喜欢看动漫，有的喜欢林志玲，有的喜欢听摇滚。但是他们可能在天冷的时候都会穿毛衣，有穿美特斯邦威的，有穿以纯的。那么我们在写代码的时候，知道接口都有穿毛衣这个方法，针对不同的毛衣，我们创建不同的实例，只要号码没问题，都可以穿上。扩展起来是不是很方便。
我们看到，是针对更加抽象的interface来编程，具体的类依赖于抽象的接口。即对于具体的类来说，不要互相依赖，而要针对接口编程。
这张图我们也可以比较直观的看到依赖反转原则的应用。
依赖反转原则基于这样的情况：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。
使用DIP的优点：
减少类之间的耦合提高系统的稳定性提高系统的可维护性和可扩展性
当然，使用这个原则会导致有更多的类和接口来维护，但是更加灵活。 依赖反转原则不应该盲目使用在模块中。比如一些功能类之类的，则不需要使用这个原则。
最佳实践：
每个类尽量有借口或者抽象类变量的类型尽量声明为借口或者抽象类尽量不要复写父类的方法结合里氏替换原则来使用
参考：
/wiki/Dependency_inversion_principle
/moxiaoya1314/article/details/51899048
https://springframework.guru/principles-of-object-oriented-design/dependency-inversion-principle
《设计模式之禅》
[《The Dependency Inversion Principle》](
