依赖倒置原则
什么是依赖倒置原则:
高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
针对接口编程，不要针对实现编程
即:
每个类尽量继承自接口或者抽象类
优点：减少类之间的耦合，提高代码的稳定性，代码的可读性维护性。
案例：
背景：
现在有一个用户类叫Ggzx（也就是我），想要学习一些课程，简单的来实现调用学习的方法，然后在一个Test类之中输入学习的内容。但是我暂时只学java和web，但是可能我后面还要学习Spring,SpringMVC…
1.面向实现编程
public class Ggzx {
public void stduyJava(){
System.out.println("学习了java课程");
}
public void studyWeb(){
System.out.println("学习了Web课程");
}
}
public class Test {
public static void main(String[] args) {
Ggzx ggzx=new Ggzx();
ggzx.studyJava();
ggzx.studyPython();
ggzx.studyGo();
}
}
分析：
上面使用的面向实现编程，但是Test作为我们控制的"应用层",也就是高层，而Ggzx作为低层,其实这样在比较简单的例子中，其实是没问题的，因为假如不需要扩展，仅仅是实现两个很简单的功能，并没有必要去面向接口开发，但是一般在开发中通常有很复杂的开发环境和开发需求。
现在如果想添加新的功能，学习其他的课程，怎么办？？？
继续使用面向实现编程，直接在 Ggzx 类中直接添加新的方法，可以完成这个功能需求。
用上面的方法实现有没有缺点？？？
1.学习的课程和 Ggzx 类耦合比较严重。是学习的课程只能通过Ggzx 才能得到 。并且是想要学习新的课程也要在 Ggzx 类中不断添加和修改 —>高耦合
2.Ggzx 作为当前 demo 的底层，经常的被改动，高层Test依赖于低层 Ggzx 的实现 ---->对应依赖倒置原则中的:高层过度依赖低层了
2.面向接口编程(简单版)
为了解决上面出现的问题，我们可以考虑把学习的课程抽出来成为一个类。到现在，类和类之间的耦合其实就已经降低很多了。然后将其当做参数传入Ggzx里面，然后调用课程里面的学习方法
//web课程类
public class WebCourse {
public void studyCourse() {
System.out.println("学习了Web课程");
}
}
//这里是Java课程类
public class JavaCourse {
public void studyCourse() {
System.out.println("学习Java课程");
}
}
当我们写出来这两个类，想要对Ggzx里面的学习方法进行编写的时候，有没有发现其实有一些小问题呢？？？？
Ggzx里面接收这些类的参数是什么？？
难道要这样?
//以下是Ggzx类中的内容
public void studyJava(JavaCourse javaCourse){
}
public void studyWeb(WebCourse webCourse){
}
nonono,如果这样做，虽然当前已经把课程类和 Ggzx 用户剥离一点点了，但是是还是形同虚设，课程类虽然分离开了，但是还是像狗皮膏药一样贴在 Ggzx 类中，但是看着还是很难受，高层 Test 调用方法还是得依赖 Ggzx 里面有什么方法
- 每次加入新课程，都需要修改底层功能
如何修改？？？
接口是个好东西，课程类之间是不是都包含同样一个方法，被学习的方法( studyCourse )，那么我们可以将所有课程类都实现一个ICourse课程！
对应上面的问题，我们该传入什么参数能解决问题？？可以传入一个接口
改编后的 UML 图解展示（Ggzx 被废弃，用新的 NewGgzx 代替）：
(如果没了解过UML类图，或者是纯小白，只需要知道一个大框是一个类，虚线表示实现了箭头方向的接口，小m是方法 即可)
观察上面的UML图
WebCourse 和 JavaCourse 实现自同一个接口 ICourse，每个课程都有自己的 studyXxx 方法。
这样好在什么地方？
课程类和Ggzx类是解耦的，无论你增加多少个课程类，只要实现了ICourse接口，都能直接传入Ggzx的studyMyCourse()方法中
public interface ICourse {
void studyCourse();
}
public interface ICourse {
void studyCourse();
}
public class NewGgzx {
public void studyMyCourse(ICourse iCourse){
iCourse.studyCourse();
}
}
上面就是案例的面向接口编程，我们可以看到，在 NewGgzx 类中，我们可以传入一个实现 ICourse 接口的课程类，我们在Test类中调用的时候，只需要传入一个课程类即可调用学习方法,这样当想扩展新的内容，只需要创建一个新的课程类实现 ICourse 即可
Test使用
NewGgzx newGgzx =new NewGgzx(); newGgzx.studyMoocCourse(new WebCourse()); newGgzx.studyMoocCourse(new com.ggzx.design.priciple.dependenceiversion.JavaCourse());
从面向实现到面向接口，我们处理问题的方法改变了：
- 开始时，我们需要考虑在Test类中调用Ggzx里面的哪一种学习方法，即注重调用什么方法能够实现特定的课程
- 到面向接口编程，我们考虑传入什么课程即可实现学习
当业务需求拓展时，拓展方法也改变了：
- 面向实现：需要改变底层的代码来协调我们需要使用的功能，用上面的例子来解释就是：当你想要学习一个课程，你就需要改变你底层的实现，增加新的代码
- 面向接口：想学习什么课程，不会对其他课程造成影响，也不会影响到低层的Ggzx 。实际操作就是增加一门新的课程即可，实现接口之后，传入这个类到Ggzx的方法中就可以学习这一门课了
相对于细节的多变性，抽象的东西更稳定，以抽象为基础搭建的架构比以细节搭建的架构更加稳定
总结
本篇文章就到这里了，希望能够给你带来帮助，也希望您能够多多关注脚本之家的更多内容!