深入浅出设计模式——依赖倒转原则

1.依赖倒转原则介绍

2.用代码演示依赖倒转原则

3.总结

1.依赖倒转原则介绍

定义：

1）高层模块不应该依赖底层模块，两者都应该依赖于抽象
2）抽象不应该依赖细节，细节应该依赖抽象
3）依赖倒转的中心思想是面向接口编程
4）依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西更稳定，以抽象为基础搭建的架构比细节为基础的架构稳定的多，在java中，抽象指的是接口或者抽象类，细节就是指具体的实现类。
5）使用接口或者抽象类的目的是制定好规范，而不涉及任何其具体的操作，把展现细节的任务交给他们的实现类去完成。

问题描述：依赖倒置原则体现的最明显的，也就是我们连接数据库的操作，但是当我们要换数据库的时候，如果代码写的维护性不是很高，就可能导致换一种数据库就要在很多地方重新硬编码一下，这样的代码架构不是非常稳定，因为他们不依赖于抽象，而是依赖于实际的细节。那如何让我们连接数据库的时候，可以随时切换不同数据库，不依赖具体的实现细节，而依赖于抽象呢？

解决方法：我们都知道，在连接数据库的时候，我们要导入不同的jar包，mysql的就导入mysql的包，oracle就导入oracle的包，sqlServer就导入sqlServer的包。java只要定义好抽象的连接方法，具体实现只需要交给厂家去实现就可以了，我们写的service类，也只是依赖于抽象的连接方法，并没有依赖具体的连接方法，而具体的实现，则让厂家自己去实现就行了，所以可以随时切换数据库驱动包。

2.用代码演示依赖倒转原则

需求场景：假设我们要制作一个用户能够完成任务并给予积分奖励的系统，因为每个任务都不同，所以我们就会编写非常多的不同任务的完成逻辑，比如阅读任务，点赞任务，浏览任务，每个任务一段代码，就会使代码量非常大，而且不易修改。

public void excuteTask(String taskType){

  if(taskType == "阅读任务"){
    //执行逻辑
  }

  if(taskType == "点赞任务"){
  //执行逻辑
  }

}

此时，这个方法就依赖于实现细节，而不是依赖于抽象，这很容易导致一个方法有上千行，而且如果是多人协作开发，会导致源源不断的冲突。

改进：我们将将业务执行逻辑抽象出来，每个对应的任务完成逻辑类都去实现它。

public interface TaskExcute(){

public void excute();

}

public class ReadTask implements TaskExcute {

 
public void excute(){
     // 阅读任务执行逻辑
}

}

public class LikeTask implements TaskExcute {

 
public void excute(){
     // 点赞任务执行逻辑
}

}

这样，高层就只需要依赖TaskExcute这个接口就可以了，实现细节将由子类去实现。完成了依赖倒置原则的目标。

3.总结

采用依赖倒置原则的时候，尤其是在多人并行开发方面，有很大的优势，一群开发人员不需要对于一个方法进行修改，我们可以同时开工，不受影响。

依赖倒置的核心原则就是要面向接口编程，理解了面向接口编程，也就理解了依赖倒置。