依赖倒置原则的原始定义为包含三个方面:
高层模块和底层模块可能好理解些,因为每一个逻辑的实现都是由原子逻辑组成的,不可分割的原子逻辑就是低层模块,原子逻辑的再组装就是高层模块。那什么是抽象,什么是细节呢?我们不妨回到 Java 语言本身去找答案吧:在 Java 中,抽象指接口或抽象类,两者均不能被实例化;细节就是实现类,实现类继承抽象类或实现接口,特点在于可被实例化,所以依赖倒置原则在 Java 中的体现为:
在说明之前我先举个学生打LOL的例子吧:
public class Student {
public void playGame(LoL lol){
System.out.println("打游戏");
}
}
public class LoL {
public void play() {
System.out.println("我爱LOL");
}
}
很普通的逻辑对吧?但大家都知道,有些学生喜欢打LOL,有些学生喜欢打DOTA啊,那怎么办?许多人第一反应就是:添加一个类呗
public class DOTA {
public void play() {
System.out.println("我爱DOTA");
}
}
但添加以后问题就来了,Student 要怎么玩DOTA?我们只能乖乖地在 Student 类里添加方法,才能让 Student 玩DOTA:
public class Student {
public void playGame(LoL lol){
System.out.println("打游戏");
}
public void playGame(DOTA dota){
System.out.println("打游戏");
}
}
观察力敏锐的人现在可能已经察觉了,我们每一次为了实际逻辑对类进行修改时,按照这种代码架构思想来修改的话,必然会做大量的无用功,随着逻辑变得复杂,代码也将不可避免地变得越来越难读。除此以外,代码还会因逻辑的添加和修改不断地修改,那么问题来了,修改带来的 Bug 谁来处理?发生大问题的时候锅给谁?
除此以外,现在进行软件开发一般都是团队协作开发,也就是说,对某个大功能块进行开发时,会划分为多个小功能模块进行开发,如果我们按照刚刚那样进行开发,把这样的代码提供给队友用,你觉得沟通效率会高吗?
这是以上的问题,导致了依赖倒置原则的诞生,依赖倒置原则就是用来减少类间耦合,提高系统的稳定性,可维护性,代码可读性的。我们不妨看看用依赖倒置原则重构的代码的例子:
首先引入抽象类 Game:
public abstract class Game {
public abstract void play();
}
LOL 和 DOTA 类都不改变,只是让它们继承于 Game 类:
public class LoL extends Game{
public void play() {
System.out.println("我爱LOL");
}
}
public class DOTA extends Game{
public void play() {
System.out.println("我爱DOTA");
}
}
修改 Student 类,让它依赖于抽象:
public class Student {
public void playGame(Game game){
game.play();
}
}
经过重构之后,我们无论添加多少个游戏,都不需要修改 Student 类,除非 Game 的抽象逻辑发生了改变。
原文地址:http://blog.csdn.net/u012403246/article/details/46042149