java设计模式之依赖倒置原则

依赖倒置原则（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 abstractions。翻译过来，包含三层含义

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

上面三个问题会结合代码讲解,这样一讲就知道怎么回事了,不然看描述文字太累,而且不容易理解

高层模块和低层模块容易理解，每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。那什么是抽象，什么又是细节呢？在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的表现就是：

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

现在通俗的解释下几个名词意思

细节：细节就是一个类去实现一个接口或者继承一个抽象类,一定有一个或者多个一定要实现的方法,这方法里做什么事,你写什么代码,肯定是按照你需求去写代码的,这些就是细节

抽象不应该依赖细节：这话怎么理解,其实就是你在接口中定义的抽象方法或者在抽象类中定义的抽象方法和一个类去实现这个接口的时候 具体在方法中写什么代码没关系,所以叫抽象不应该依赖

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

现在通过代码的方式以便更好理解这个原则：

现在的汽车越来越便宜了，也就顶多一个卫生间的价格就可以买到一辆不错的汽车，有汽车就必然有人来驾驶了，司机驾驶奔驰车

在这个需求中我们可以提出关键的名词作为类比如汽车是一个类,司机是一个类,那么行为呢?也就是方法,驾驶就是一个方法,汽车得有个跑的动作, 那么这二个类怎么关联在一起呢?

根据上面的分析：写一个Driver类表示司机 司机有有开车行为,

Driver{

        public void drive(){

        }

}

这里面只有一个drive()方法，车谁来开啊,当然是司机了,司机当然开的是车了,所以要把车这个类通过deive()方法传递进来

Driver{

        public void drive(Benz benz){

              benz.run();

        }

}

司机通过调用奔驰车的run方法开动奔驰车

class Benz{

      public void run(){

            System.out.println("奔驰汽车动起来------------");

      }

}

现在写一个测试类去测试一下Client ：

public class Client {

 public static void main(String[] args) {

  Driver zhangSan = new Driver();

  Benz benz = new Benz();

  //张三开奔驰车

  zhangSan.drive(benz);

 }

}

 通过以上的代码，完成了司机开动奔驰车的场景，到目前为止，这个司机开奔驰车的项目没有任何问题。随着业务需求变更永无休止，技术前进就永无止境，在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？麻烦出来了，那好，我们走一步是一步，我们先把宝马车产生出来

public class BMW {

 public void run(){

 System.out.println("宝马汽车开始运行...");

 }

}

那我们是不是要在Driver类中再添加一个方法

Driver{

        public void drive(Benz benz){

              benz.run();

        }

      public void drive(BMW bmw){

                 bmw.run()；

       }

}

现在车很多,如果再加入100部车,那么是不是要在Driver中添加100个run()方法让不同的司机开不同的车么,

果就是系统的可维护性大大降低，可读性降低，两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本，这样的依赖关系谁肯承担

如果不使用依赖倒置原则就会加重类间的耦合性，降低系统的稳定性，增加并行开发引起的风险，降低代码的可读性和维护性,看下面的类图

从这个类图中我们发现定义了一个接口IDriver,它有个抽象方法 driver(ICar car)而ICar也是个接口,这接口中有run（）方法,我们现在根据这个类图去写代码：

IDriver.java

public interface IDriver {

 //是司机就应该会驾驶汽车

 public void drive(ICar car);

}

ICar.java

public interface ICar {

 //是汽车就应该能跑

 public void run();

}

Driver.java 实现了IDriver接口

public class Driver implements IDriver {

 @Override

 public void drive(ICar car) {

  car.run();

 }

}

Benz.java 实现了ICar接口

public class Benz implements ICar{

 @Override

 public void run() {

  System.out.println("奔驰被开动了---");

 }

}

BMW.java 实现了ICar接口

public class BMW implements ICar {

 public void run(){

 System.out.println("宝马汽车开始运行...");

 }

}

测试Client.java

public class Client {

 public static void main(String[] args) {

  IDriver zs = new Driver();

  ICar benz = new Benz();

  ICar bmw = new BMW();

  //张三开奔驰车

  zs.drive(benz);

  //张三开宝马

  zs.drive(bmw);

 }

}

ok，设计完毕

从上面的设计来看,

不管你添加多少个车,都是放在driver,因为driver()接受的是一个接口,所以可以接受不同的车driver中,当然IDriver也可以写成一个抽象类,但是一般都不写成抽象类,都写成接口形式

建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法

接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成

在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car需要在高层模块中声明

依赖就是没这个不行了,意思是说在driver方法中不传入ICar接口,这个抽象方法就不能使用了,什么叫抽象之间的依赖,就是一个接口中依赖另一个接口,或者一个抽象类中依赖另一个抽象类,

高层模块就是最终在哪里调用那个就是高层模块

 在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此我们在高层次的模块中应用都是抽象

为什么说在高层次的模块中应用都是抽象,比如Client就是高层模块,它依赖了ICar,IDriver这二个接口，他不是依赖一个个具体的类,

 Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，zhangSan的显示类型是IDriver，benz的显示类型是ICar，也许你要问，在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释？确实如此，zhangSan的显示类型是IDriver，是一个接口，是抽象的，非实体化的，在其后的所有操作中，zhangSan都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。当然，张三如果要开宝马车，也很容易，我们只要修改业务场景类就可以

依赖的三种写法

依赖是可以传递的，A对象依赖B对象，B又依赖C，C又依赖D…，生生不息，依赖不止，记住一点：只要做到抽象依赖，即使是多层的依赖传递也无所畏惧

对象的依赖关系有三种方式来传递

1):构造函数传递依赖对象

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

如果使用这种很不好,因为Driver就要构造很多对象

2）：Setter方法传递依赖对象

在抽象中设置setter方法声明依赖关系，依照依赖注入的说法就是setter依赖注入，按照这种方式的注入

3):在接口的方法中声明依赖对象，3.2章节的例子就是采用了接口声明依赖的方式，，该方法也叫做接口注入,就是我们最先讲到的方式

 最佳实践

依赖倒转原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合，我们怎么在项目中使用这个规则呢？只要遵循以下的几个规则就可以：

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

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

• 变量的显示类型尽量是接口或者是抽象类。

     很多书上说变量的类型一定要是接口或者是抽象类，这个有点绝对化了，比如一个工具类，xxxUtils一般是不需要接口或是抽象类的。还有，如果你要使用类的clone方法，就必须使用实现类，这个是JDK提供一个规范。

• 任何类都不应该从具体类派生。

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

• 尽量不要覆写基类的方法。

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

• 结合里氏替换原则使用

     在上一个章节中我们讲解了里氏替换原则，父类出现的地方子类就能出现，再结合本章节的讲解，我们可以得出这样一个通俗的规则： 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

     讲了这么多，估计大家对“倒置”这个词还是有点不理解，那到底什么是“倒置”呢？我们先说“正置”是什么意思，依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑就直接依赖笔记本电脑，而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的。

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

     依赖倒置原则是六个设计原则中最难以实现的原则，它是实现开闭原则的重要途径，依赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。在项目中，大家只要记住是“面向接口编程”就基本上抓住了依赖倒转原则的核心。

     讲了这么多依赖倒置原则的优点，我们也来打击一下大家，在现实世界中确实存在着必须依赖细节的事物，比如法律，就必须依赖细节的定义。 “杀人偿命”在中国的法律中古今有之，那这里的杀人就是一个抽象的含义，怎么杀，杀什么人，为什么杀人，都没有定义，只要是杀人就统统得偿命，那这就是有问题了，好人杀了坏人，还要陪上自己的一条性命，这是不公正的，从这一点看，我们在实际的项目中使用依赖倒置原则时需要审时度势，不要抓住一个原则不放，每一个原则的优点都是有限度的，并不是放之四海而皆准的真理，所以别为了遵循一个原则而放弃了一个项目的终极目标：投产上线和盈利。作为一个项目经理或架构师，应该懂得技术只是实现目的的工具，惹恼了顶头上司，设计做得再漂亮，代码写得再完美，项目做得再符合标准，一旦项目亏本，产品投入大于产出，那整体就是扯淡！你自己也别想混得更好