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

客官°小女子只卖身不卖艺 2022-05-25 09:40 127阅读 0赞

依赖倒置原则(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**