依赖倒置原则------依赖的三种方法

依赖倒置原则(Dependence Inversion Principle ,DIP)定义如下：

High level modules should not depend upon low level modules,Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstracts.

翻译过来为：

• 高层模块不应该依赖低层模块，两者都应该依赖抽象
• 抽象不应该依赖细节
• 细节应该依赖抽象

也可以说高层模块，低层模块，细节都应该依赖抽象

每一个逻辑的实现都是由颗粒原子逻辑组成的，颗粒原子逻辑就是低层模块，而颗粒原子逻辑组成的模块就是高层模块。在java语言中，抽象就是接口或抽象类，两都都是不能直接被实例化的，细节就是实现类，实现接口或继承抽象类而产生的类就是细节，两者都可以直接被实例化。

依赖倒置原则在java语言中，表现是：

• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
• 接口或抽象类不依赖实现类
• 实现类依赖接口或抽象类

更加精简的定义就是“面向接口编程”—OOD(Object-Oriented Design，面向对象设计)的精髓之一。

依赖倒置原则的好处

采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定，降低并行开发引起的风险，提高代码的可读性和可维护性。

为什么我们要符合依赖倒置原则

我们通过一个例子说明依赖倒置原则对于开发有上面的好处。

大家都喜欢阅读，阅读文学经典滋润自己的内心心灵，下面是小明同学阅读文学经典的示例：

文学经典的源代码：

//文学经典类
public class LiteraryClassic{
    //阅读文学经典
    public void read(){
       System.out.println("文学经典阅读，滋润自己的内心心灵");
    }
}

小明类：

//小明类
public class XiaoMing{
    //阅读文学经典
    public void read(LiteraryClassic literaryClassic){
        literaryClassic.read();
    }
}

场景类：

public class Client{
   public static void main(Strings[] args){
      XiaoMing xiaoming = new XiaoMing();
      LiteraryClassic literaryClassic = new LiteraryClassic();
      //小明阅读文学经典
      xiaoming.read(literaryClassic);
   }

}

看，我们的实现，小明同学可以阅读文学经典了。

小明同学看了一段文学经典后，忽然他想看看看小说来放松一下自己,我们实现一个小说类：

小说类源代码

//小说类
public class Novel{
    //阅读小说
    public void read(){
       System.out.println("阅读小说，放松自己");
    }
}

现在我们再来看代码，发现XiaoMing类的read方法只与文学经典LiteraryClassic类是强依赖，紧耦合关系，小明同学竟然阅读不了小说类。这与现实明显的是不符合的，代码设计的是有问题的。那么问题在那里呢？

我们看小明类，此类是一个高层模块，并且是一个细节实现类，此类依赖的是一个文学经典LiteraryClassic类，而文学经典LiteraryClassic类也是一个细节实现类。这是不是就与我们说的依赖倒置原则相违背呢？依赖倒置原则是说我们的高层模块，实现类，细节类都应该是依赖与抽象，依赖与接口和抽象类。

为了解决小明同学阅读小说的问题，我们根据依赖倒置原则先抽象一个阅读者接口,下面是示例：

IReader接口：

public interface IReader{
   //阅读
   public void read(IRead read){
       read.read();
   }

}

再定义一个被阅读的接口IRead:

public interface IRead{
   //被阅读
   public void read();
}

再定义文学经典类和小说类： 

文学经典类：

//文学经典类
public class LiteraryClassic implements IRead{
    //阅读文学经典
    public void read(){
       System.out.println("文学经典阅读，滋润自己的内心心灵");
    }
}

小说类:

//小说类
public class Novel implements IRead{
    //阅读小说
    public void read(){
       System.out.println("阅读小说，放松自己");
    }
}

再实现小明类：

//小明类
public class XiaoMing implements IReader{
    //阅读
    public void read(IRead read){
        read.read();
    }
}

然后，我们再让小明分别阅读文学经典和小说：

Client:

public class Client{
   public static void main(Strings[] args){
      XiaoMing xiaoming = new XiaoMing();
      IRead literaryClassic = new LiteraryClassic();
      //小明阅读文学经典
      xiaoming.read(literaryClassic);

      IRead novel = new Novel();
      //小明阅读小说
      xiaoming.read(novel);
   }

}

至此，小明同学是可以阅读文学经典，又可以阅读小说了，目的达到了。

为什么依赖抽象的接口可以适应变化的需求？这就要从接口的本质来说，接口就是把一些公司的方法和属性声明，然后具体的业务逻辑是可以在实现接口的具体类中实现的。所以我们当依赖对象是接口时，就可以适应所有的实现此接口的具体类变化。

依赖的三种方法

依赖是可以传递，A对象依赖B对象，B又依赖C，C又依赖D，……，依赖不止。只要做到抽象依赖，即使是多层的依赖传递也无所谓惧。 
对象的依赖关系有三种方式来传递：

构造函数传递依赖对象

在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫做构造函数注入：

构造函数注入：

//小明类
public class XiaoMing implements IReader{
     private IRead read;
     //构造函数注入
     public XiaoMing(IRead read){
        this.read = read;
     }

    //阅读
    public void read(){
        read.read();
    }
}

Setter方法传递依赖对象

在类中通过Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入：

//小明类
public class XiaoMing implements IReader{
     private IRead read;
     //Setter依赖注入
     public setRead(IRead read){
        this.read = read;
     }

    //阅读
    public void read(){
        read.read();
    }
}

接口声明依赖

在接口的方法中声明依赖对象，在为什么我们要符合依赖倒置原则的例子中，我们采用了接口声明依赖的方式，该方法也叫做接口注入。

依赖倒置原则的经验

依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。我们在项目中使用这个原则要遵循下面的规则：

• 每个类尽量都有接口或者抽象类，或者抽象类和接口两都具备
• 变量的表面类型尽量是接口或者抽象类
• 任何类都不应该从具体类派生
• 尽量不要覆写基类的方法 
  如果基类是一个抽象类，而这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会有一定的影响。
• 结合里氏替换原则使用 
  里氏替换原则：父类出现的地方子类就能出现。结合本章我们得出了一个通俗的规则：接口负责定义public属性和方法，并且声明与其他对象的依赖关系。抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

依赖倒置原则是6个设计原则中最难以实现的原则，它是实现开闭原则的重要方法，在项目中，大家只要记住是”面向接口编程”就基本上是抓住了依赖倒置原则的核心了。

本文转自：

https://blog.csdn.net/hfreeman2008/article/details/52289571