【设计原则】依赖倒置原则 (面向接口编程)

本文将以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 class WebCourse implements ICourse{

    @Override
    public void studyCourse() {
        System.out.println("学习了Web课程");
    }
}

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

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