[转]设计模式六大原则[3]：依赖倒置原则

定义：高层模块不该该依赖低层模块，两者都应该依赖其抽象；抽象不该该依赖细节；细节应该依赖抽象。

问题由来：类A直接依赖类B，假如要将类A改成依赖类C，则必须经过修改类A的代码来达成。这种场景下，类A通常是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操做；假如修改类A，会给程序带来没必要要的风险。

解决方案：将类A修改成依赖接口I，类B和类C各自实现接口I，类A经过接口I间接与类B或者类C发生联系，则会大大下降修改类A的概率。

　　依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操做，把展示细节的任务交给他们的实现类去完成。

　　依赖倒置原则的核心思想是面向接口编程，咱们依旧用一个例子来讲明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的，母亲给孩子讲故事，只要给她一本书，她就能够照着书给孩子讲故事了。代码以下：

class Book{  
    public String getContent(){  
        return "好久好久之前有一个阿拉伯的故事……";  
    }  
}  
  
class Mother{  
    public void narrate(Book book){  
        System.out.println("妈妈开始讲故事");  
        System.out.println(book.getContent());  
    }  
}  
  
public class Client{  
    public static void main(String[] args){  
        Mother mother = new Mother();  
        mother.narrate(new Book());  
    }  
}  

运行结果：

妈妈开始讲故事
好久好久之前有一个阿拉伯的故事……

　　运行良好，假若有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事，报纸的代码以下：

class Newspaper{  
    public String getContent(){  
        return "林书豪38+7领导尼克斯击败湖人……";  
    }  
} 

　　这位母亲却办不到，由于她竟然不会读报纸上的故事，这太荒唐了，只是将书换成报纸，竟然必需要修改Mother才能读。假如之后需求换成杂志呢？换成网页呢？还要不断地修改Mother，这显然不是好的设计。缘由就是Mother与Book之间的耦合性过高了，必须下降他们之间的耦合度才行。

　　咱们引入一个抽象的接口IReader。读物，只要是带字的都属于读物：

interface IReader{  
    public String getContent();  
}  

　　Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改成：

class Newspaper implements IReader {  
    public String getContent(){  
        return "林书豪17+9助尼克斯击败老鹰……";  
    }  
}  
class Book implements IReader{  
    public String getContent(){  
        return "好久好久之前有一个阿拉伯的故事……";  
    }  
}  
  
class Mother{  
    public void narrate(IReader reader){  
        System.out.println("妈妈开始讲故事");  
        System.out.println(reader.getContent());  
    }  
}  
  
public class Client{  
    public static void main(String[] args){  
        Mother mother = new Mother();  
        mother.narrate(new Book());  
        mother.narrate(new Newspaper());  
    }  
} 

运行结果：

妈妈开始讲故事
好久好久之前有一个阿拉伯的故事……
妈妈开始讲故事
林书豪17+9助尼克斯击败老鹰……

　　这样修改后，不管之后怎样扩展Client类，都不须要再修改Mother类了。这只是一个简单的例子，实际状况中，表明高层模块的Mother类将负责完成主要的业务逻辑，一旦须要对它进行修改，引入错误的风险极大。因此遵循依赖倒置原则能够下降类之间的耦合性，提升系统的稳定性，下降修改程序形成的风险。

　　采用依赖倒置原则给多人并行开发带来了极大的便利，好比上例中，本来Mother类与Book类直接耦合时，Mother类必须等Book类编码完成后才能够进行编码，由于Mother类依赖于Book类。修改后的程序则能够同时开工，互不影响，由于Mother与Book类一点关系也没有。参与协做开发的人越多、项目越庞大，采用依赖致使原则的意义就越重大。如今很流行的TDD开发模式就是依赖倒置原则最成功的应用。

　　传递依赖关系有三种方式，以上的例子中使用的方法是接口传递，另外还有两种传递方式：构造方法传递和setter方法传递，相信用过Spring框架的，对依赖的传递方式必定不会陌生。
在实际编程中，咱们通常须要作到以下3点：

• 低层模块尽可能都要有抽象类或接口，或者二者都有。
• 变量的声明类型尽可能是抽象类或接口。
• 使用继承时遵循里氏替换原则。

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