什么是依赖倒置原则

什么是依赖倒置原则

一、依赖倒置原则

即

1、高层模块不应该依赖低层模块，两者都应该依赖于抽象（抽象类或接口）

2、抽象（抽象类或接口）不应该依赖于细节（具体实现类）

3、细节（具体实现类）应该依赖抽象

抽象：即抽象类或接口，是不能够实例化的。

细节：即具体的实现类，实现接口或者继承抽象类所产生的类，可以通过关键字new直接被实例化。

二、依赖倒置遵循以下的几个规则

1、每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备

这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。

2、任何类都不应该从具体类派生

如果一个项目处于开发状态，确实不应该有从具体类派生出的子类的情况，但这也不是绝对的，因为人都是会犯错误的，有时设计缺陷是在所难免的，因此只要不超过两层的继承都是可以忍受的。特别是做项目维护的同志，基本上可以不考虑这个规则，为什么？维护工作基本上都是做扩展开发，修复行为，通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必再要去继承最高的基类呢？

3、尽量不要覆写基类的方法

如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。

4、结合里氏替换原则使用

 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

三、依赖倒置原则的优点

在小型项目中很难体现出来，例如小于10个人月的项目，使用简单的架构，基本上不费太大力气就可以完成，是否采用依赖倒置原则影响不大。但是，在一个大中型项目中，采用依赖倒置原则可以带来非常多的优点，特别是规避一些非技术因素引起的问题。项目越大，需求变化的概率也越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的，如果设计优良、代码结构清晰，人员变化对项目的影响基本为零。大中型项目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展和维护。

四、依赖倒置实现方式

1、构造函数传递依赖对象

在类中通过构造函数声明依赖对象，比如在构造函数中的需要传递的参数是抽象类或接口的方式实现。

例如

public interface IDriver 
...{
 
//是司机就应该会驾驶汽车
 
public void drive();
 
}
 
public class Driver : IDriver
...{
 
  private ICar car;
 
  //构造函数注入
 
  public Driver(ICar _car)
  ...{
 
  this.car = _car;
 
  }
 
  //司机的主要职责就是驾驶汽车
 
  public void drive()
  ...{
 
    this.car.run();
 
  }
 
}

			

2、Setter方法传递依赖对象

在抽象中设置setter方法声明依赖关系，即在我们设置的setXXX方法中的参数为抽象类或接口，来实现传递依赖对象

例如

public interface IDriver 
...{
 
  //车辆型号
 
  public void setCar(ICar car);
 
  //是司机就应该会驾驶汽车
 
  public void drive();
 
}
 
public class Driver : IDriver
...{
 
  private ICar car;
 
  public void setCar(ICar car)
  ...{
 
    this.car = car;
 
  }
 
  //司机的主要职责就是驾驶汽车
 
  public void drive()
  ...{
 
    this.car.run();
 
  }
 
}

		

3、接口声明依赖对象

在接口的方法中声明依赖对象,即在函数声明中参数为抽象类或接口，来实现传递依赖对象，从而达到直接使用依赖对象的目的。