详解Java设计模式编程中的依赖倒置原则
内容摘要
定义：
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来
文章正文
定义：
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
依赖倒置原则的核心思想是面向接口编程，我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了。
例子：
违法依赖倒置的情况
public class Student {
public void read(Book book){
System.out.println("学生开始阅读："+book.getName());
}
}
public class Book {
public String getName() {
return "书籍";
}
}
当学生需要阅读网页时，就需要修改Student类，这是很不友好的设计。下面我们看遵守依赖倒置原则的例子。
public interface Person {
public void read(Reader reader);
}
public interface Reader {
public String getName();
}
public class Student implements Person{
@Override
public void read(Reader reader) {
System.out.println("学生开始阅读："+reader.getName());
}
}
public class Book implements Reader {
public String getName() {
return "书籍";
}
}
public class Website implements Reader {
public String getName() {
return "网页";
}
}
public class Test {
public static void main(String[] args) {
Person student = new Student();
student.read(new Book());
student.read(new Website());
}
}
在read方法中我们使用了接口作为参数。
总结：
1. 每个类最好有接口或者抽象类，或者同时接口和抽象类都有。
2. 变量声明最好是接口或者抽象类。
3. 继承时遵守里氏替换原则。
代码注释
作者：喵哥笔记
