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课程!
对应上面的问题,我们该传入什么参数能解决问题??可以传入一个接口
改编后的 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的方法中就可以学习这一门课了
相对于细节的多变性,抽象的东西更稳定,以抽象为基础搭建的架构比以细节搭建的架构更加稳定
总结
本篇文章就到这里了,希望能够给你带来帮助,也希望您能够多多关注我们的更多内容!