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

依赖倒置原则

什么是依赖倒置原则:

高层模块不应该依赖低层模块，二者都应该依赖其抽象

抽象不应该依赖细节，细节应该依赖抽象

针对接口编程，不要针对实现编程

即:

每个类尽量继承自接口或者抽象类

优点：减少类之间的耦合，提高代码的稳定性，代码的可读性维护性。

案例：

背景：

现在有一个用户类叫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的方法中就可以学习这一门课了

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

总结