java的依赖倒置原则你了解多少 java的依赖倒置原则你了解多少

依赖倒置原则
案例：

背景：

1.面向实现编程
2.面向接口编程(简单版)

总结

依赖倒置原则什么是依赖倒置原则:
高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
针对接口编程，不要针对实现编程
即:
每个类尽量继承自接口或者抽象类
优点：减少类之间的耦合，提高代码的稳定性，代码的可读性维护性。

案例：
背景：
现在有一个用户类叫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课程！
对应上面的问题，我们该传入什么参数能解决问题？？可以传入一个接口
【java的依赖倒置原则你了解多少】改编后的 UML 图解展示（Ggzx 被废弃，用新的 NewGgzx 代替）：

文章图片

(如果没了解过UML类图，或者是纯小白，只需要知道一个大框是一个类，虚线表示实现了箭头方向的接口，小m是方法即可)
观察上面的UML图
WebCourse 和 JavaCourse 实现自同一个接口 ICourse，每个课程都有自己的 studyXxx 方法。
这样好在什么地方？
课程类和Ggzx类是解耦的，无论你增加多少个课程类，只要实现了ICourse接口，都能直接传入Ggzx的studyMyCourse()方法中

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的方法中就可以学习这一门课了

相对于细节的多变性，抽象的东西更稳定，以抽象为基础搭建的架构比以细节搭建的架构更加稳定