一、前言

• 依赖倒置原则也称依赖倒转原则（Dependence Inversion Principle）

看官方定义

• 高层模块不应该依赖底层模块，二者都应该依赖其抽象

• 抽象不应该依赖细节，细节应该依赖抽象

• 依赖倒置的中心思想是面向接口编程

• 如果你了解点设计模式，应该理解上面的话，但是如果不了解的话，感觉说的云里雾里的，是不是一脸懵，懵这就对了，那就先看例子吧，会帮助你理解的！

二、举例说明

2.1 例子介绍（无聊的可看看，着急的请跳过）

• 能看下面的类图就看图，能看代码就看代码，我就是简单说一下例子的想法
• 如果你问身边的人或者看网上的代码都不是自己的思想，如果你没有勇气把公司的代码都用设计模式优化一遍，那就忍着，等你的架构师忍不住的时候再动手，但是如果学完东西不实操很容易就忘记。
• 那这就需要好的例子了，其实举例也是思想得一部分，懂得多了，就信手拈来，公司中好多人都会跟你说只可意会不可言传，我挺讨厌这句话的，说了等于没说，如果你不想继续当码农，不妨把生活应用于实践，别人问你什么你能用通俗易懂的例子告诉他，你就赢了！
• 因为我养着一条狗叫麦兜，心里又喜欢着猫，想在多年后一定要养一只布偶或者德文，所以我的很多例子都是很麦兜有关系，设计来源于生活！那下面的例子就是家庭养殖场养殖各种宠物的例子

2.2 反例

2.1.1 反例1

（1）类图说明

• 先介绍一下这几个类，待会看图理解
  FamilyFarm–>家庭养殖场类，不定时的收养宠物
  DogGrowthProcess–>狗狗成长过程类，记录狗狗从出生到被收养的过程
  ClientTest–>不说了，说多了都是废话，测试类
• 通俗易懂，直接上图：
  
• 不是很明白的话，再往下看代码说明

（2）代码说明

（3）测试

（4）分析优缺点

• 咋看，没毛病，通俗易懂；再看，不便于维护，屎代码，恶心难受
• 我知道看完之后肯定觉得这段代码通俗易懂，简单的不能再简单了，而且你还会觉得，即便下次再收养个猫，复制剪贴加上就行了呀，也挺好维护的呀，真的吗？那问题是？请继续……

2.1.2 反例2——反例1上维护

（1）类图说明

（2）代码说明

（3）测试

（4）分析优缺点

1）优缺点分析

• 这样增加新功能的时候看似简单，也确实不难，但是随着项目的扩大，尤其是实际开发的项目非常的庞大，像这样每增加一个新功能，每增加一个新类你都要改养殖场类 FamilyFarm（你可以这么理解，我就是一个养殖场，你有新品种了直接给我送来就行，我为啥还要各种修改呢，我不动不行吗？你不给我提供快捷方式，我不跟你合作了……）
• FamilyFarm 是一个养殖场，可能养很多动物，具体养什么不知道，你可以把他理解抽象一点儿，而狗狗和小猫的成长过程都是具体的细节，所以 FamilyFarm 不应该依赖细节，否则就像上面代码一样后续维护困难，倒置养殖场不跟你合作了。

2）如何解决？

• 怎么解决呢，这就需要我们的依赖倒置原则了：
  FamilyFarm 不是没有依赖抽象吗？那我们就引进抽象，不让他依赖具体细节，那抽象又是怎么，怎么设置呢？
  你想呀，FamilyFarm 不能依赖狗狗猫猫成长过程的那些细节了，所以抽象就是要把狗狗猫猫羊羊🐖🐖的成长细节抽象出来，说到这里明白了吧！
• 好了，往下看例子，会更形象点，看完，我让你不想明白就难！
• 写到这里，突然觉得不继续当老师真的浪费了，害，算了算了，清醒点，别自恋了，真的养不活自己和我的麦兜，还是默默地做个码农吧！

2.3 正例

2.2.1 正例1

（1）类图说明

• 直接上图：
  
• 图说明了一切，以后再有新增动物，FamilyFarm 还会继续跟你合作，因为你让他省事到只写一次就为一生，太方便了！

（2）代码说明

（3）测试

（4）分析优缺点

• 对比反例，代码的可读性明显提高，后续维护也好维护了

2.2.2 正例2——正例1上维护（接口实现）

• 这个就不细说了，就是新增一个饲养羊的新功能，你感受一下即可

（1）类图说明

（2）代码说明

• 这就完了，就问你妙不妙，接下来就是测试了！

（3）测试

2.2.3 正例3（抽象类实现）

• 这个就不多说的了，其实是一样的思想，就是接口和抽象类的区别了，直接给图了
  
  

三、总结

3.1 倒置？为什么叫倒置？

• 看完上面案例，现在明白了吗？
• 反例：家庭农场依赖狗狗猫猫的成长过程的细节
• 正例：狗狗猫猫羊羊都继承了 petGrowthProcess 接口（即：让细节依赖抽象），家庭农场 依赖抽象，不再依赖细节；这不就倒回来了嘛

3.3 再琢磨一下官方概念

• 琢磨概念之前先简单说一下Java基础：
  在Java中，抽象指的是接口或者抽象类，而具体的实现类指的是细节。
• 依赖倒置基于细节应该依赖抽象等设计理念，相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的框架要稳定的多
• 使用接口或抽象类的目的是指定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现去完成。
• 即：依赖倒置的思想就是面向接口编程思想

3.4 作用

1. 可以降低类间的耦合性。
2. 可以提高系统的稳定性。
3. 可以减少并行开发引起的风险。
4. 可以提高代码的可读性和可维护性。

3.5 使用原则

1. 底层模块，尽量都要有抽象类或者接口，或者两者都具备，这样程序的稳定性会更好；
2. 变量的声明类型尽量是接口或者是抽象类。
3. 使用继承时尽量遵循里氏替换原则。

四、附代码

反例1

package com.liu.susu.principle.inversion.example1;

/**
 * @FileName FamilyFarm
 * @Description
 * @Author susu
 * @date 2022-02-13
 **/
public class FamilyFarm {

    public void raiseDog(DogGrowthProcess dogGrowthProcess){
        dogGrowthProcess.dogBorn();
        dogGrowthProcess.dogGrowUp();
        dogGrowthProcess.dogBeRaised();
    }
}

class DogGrowthProcess {
    public void dogBorn(){
        System.out.println("狗狗-->麦兜出生了……");
    }
    public void dogGrowUp(){
        System.out.println("狗狗-->麦兜长大了……");
    }
    public void dogBeRaised(){
        System.out.println("狗狗-->麦兜被饲养员带走了……");
    }
}

class ClientTest{
    public static void main(String[] args) {
        //狗狗长大了，开始饲养狗狗
        new FamilyFarm().raiseDog(new DogGrowthProcess());
    }
}

反例2

package com.liu.susu.principle.inversion.example2;

/**
 * @FileName Breeder
 * @Description
 * @Author susu
 * @date 2022-02-13
 **/
public class FamilyFarm {

    public void raiseDog(DogGrowthProcess dogGrowthProcess){
        dogGrowthProcess.dogBorn();
        dogGrowthProcess.dogGrowUp();
        dogGrowthProcess.dogBeRaised();
    }

    public void raiseCat(CatGrowthProcess catGrowthProcess){
        catGrowthProcess.catBorn();
        catGrowthProcess.catGrowUp();
        catGrowthProcess.catBeRaised();
    }

}

class DogGrowthProcess {
    public void dogBorn(){
        System.out.println("狗狗-->麦兜出生了……");
    }
    public void dogGrowUp(){
        System.out.println("狗狗-->麦兜长大了……");
    }
    public void dogBeRaised(){
        System.out.println("狗狗-->麦兜被饲养员带走了……");
    }
}

class CatGrowthProcess {
    public void catBorn(){
        System.out.println("小猫-->阿苔出生了……");
    }
    public void catGrowUp(){
        System.out.println("小猫-->阿苔长大了……");
    }
    public void catBeRaised(){
        System.out.println("小猫-->阿苔被饲养员带走了……");
    }
}

class ClientTest{
    public static void main(String[] args) {
        //开始饲养狗狗
        new FamilyFarm().raiseDog(new DogGrowthProcess());
        //开始饲养小猫
        new FamilyFarm().raiseCat(new CatGrowthProcess());
    }
}

正例1

package com.liu.susu.principle.inversion.example3;

/**
 * @FileName FamilyFarm
 * @Description 使用 依赖倒置原则 优化后的代码
 * @Author susu
 * @date 2022-02-13
 **/
public class FamilyFarm {

    public void raisePet(petGrowthProcess petGrowthProcess){
        petGrowthProcess.petBorn();
        petGrowthProcess.petGrowUp();
        petGrowthProcess.petBeRaised();
    }

}
interface petGrowthProcess{
    void petBorn();
    void petGrowUp();
    void petBeRaised();
}
class DogGrowthProcess implements petGrowthProcess{
    public void petBorn(){
        System.out.println("狗狗-->麦兜出生了……");
    }
    public void petGrowUp(){
        System.out.println("狗狗-->麦兜长大了……");
    }
    public void petBeRaised(){
        System.out.println("狗狗-->麦兜被饲养员带走了……");
    }
}

class CatGrowthProcess implements petGrowthProcess{
    public void petBorn(){
        System.out.println("小猫-->阿苔出生了……");
    }
    public void petGrowUp(){
        System.out.println("小猫-->阿苔长大了……");
    }
    public void petBeRaised(){
        System.out.println("小猫-->阿苔被饲养员带走了……");
    }
}

class ClientTest{
    public static void main(String[] args) {
        FamilyFarm familyFarm = new FamilyFarm();
        //饲养狗狗
        familyFarm.raisePet(new DogGrowthProcess());
        //饲养小猫
        familyFarm.raisePet(new CatGrowthProcess());
    }
}

正例2

package com.liu.susu.principle.inversion.example4;

/**
 * @FileName FamilyFarm
 * @Description 使用 依赖倒置原则 优化后的代码
 * @Author susu
 * @date 2022-02-13
 **/
public class FamilyFarm {

    public void raisePet(petGrowthProcess petGrowthProcess){
        petGrowthProcess.petBorn();
        petGrowthProcess.petGrowUp();
        petGrowthProcess.petBeRaised();
    }

}

interface petGrowthProcess{
    void petBorn();
    void petGrowUp();
    void petBeRaised();
}

class DogGrowthProcess implements petGrowthProcess{
    public void petBorn(){
        System.out.println("狗狗-->麦兜出生了……");
    }
    public void petGrowUp(){
        System.out.println("狗狗-->麦兜长大了……");
    }
    public void petBeRaised(){
        System.out.println("狗狗-->麦兜被饲养员带走了……");
    }
}

class CatGrowthProcess implements petGrowthProcess{
    public void petBorn(){
        System.out.println("小猫-->阿苔出生了……");
    }
    public void petGrowUp(){
        System.out.println("小猫-->阿苔长大了……");
    }
    public void petBeRaised(){
        System.out.println("小猫-->阿苔被饲养员带走了……");
    }
}

//新增功能饲养羊
class sheepGrowthProcess implements petGrowthProcess{
    public void petBorn(){
        System.out.println("小羊-->点点出生了……");
    }
    public void petGrowUp(){
        System.out.println("小羊-->点点长大了……");
    }
    public void petBeRaised(){
        System.out.println("小羊-->点点被饲养员带走了……");
    }
}

class ClientTest{
    public static void main(String[] args) {
        FamilyFarm familyFarm = new FamilyFarm();
        //饲养狗狗
        familyFarm.raisePet(new DogGrowthProcess());
        //饲养小猫
        familyFarm.raisePet(new CatGrowthProcess());
        //新增功能饲养羊
        familyFarm.raisePet(new sheepGrowthProcess());
    }
}

正例3

package com.liu.susu.principle.inversion.example5;

/**
 * @FileName FamilyFarm
 * @Description 使用 依赖倒置原则 优化后的代码
 * @Author susu
 * @date 2022-02-13
 **/
public class FamilyFarm {

    public void raisePet(petGrowthProcess petGrowthProcess){
        petGrowthProcess.petBorn();
        petGrowthProcess.petGrowUp();
        petGrowthProcess.petBeRaised();
    }

}

abstract class petGrowthProcess{
    public abstract void petBorn();
    public abstract void petGrowUp();
    public abstract void petBeRaised();
}

class DogGrowthProcess extends petGrowthProcess{
    public void petBorn(){
        System.out.println("狗狗-->麦兜出生了……");
    }
    public void petGrowUp(){
        System.out.println("狗狗-->麦兜长大了……");
    }
    public void petBeRaised(){
        System.out.println("狗狗-->麦兜被饲养员带走了……");
    }
}

class CatGrowthProcess extends petGrowthProcess{
    public void petBorn(){
        System.out.println("小猫-->阿苔出生了……");
    }
    public void petGrowUp(){
        System.out.println("小猫-->阿苔长大了……");
    }
    public void petBeRaised(){
        System.out.println("小猫-->阿苔被饲养员带走了……");
    }
}

//新增功能饲养羊
class sheepGrowthProcess extends petGrowthProcess{
    public void petBorn(){
        System.out.println("小羊-->点点出生了……");
    }
    public void petGrowUp(){
        System.out.println("小羊-->点点长大了……");
    }
    public void petBeRaised(){
        System.out.println("小羊-->点点被饲养员带走了……");
    }
}

class ClientTest{
    public static void main(String[] args) {
        FamilyFarm familyFarm = new FamilyFarm();
        //饲养狗狗
        familyFarm.raisePet(new DogGrowthProcess());
        //饲养小猫
        familyFarm.raisePet(new CatGrowthProcess());
        //新增功能饲养羊
        familyFarm.raisePet(new sheepGrowthProcess());
    }
}

依赖倒置原则

1 依赖倒置原则的定义

依赖倒置原则（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语言中的表现就是：

● 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关

系，其依赖关系是通过接口或抽象类产生的；

● 接口或抽象类不依赖于实现类；

● 实现类依赖接口或抽象类

更加精简的定义就是“面向接口编程”——OOD（ObjectOriented Design，面向对象设计）的精髓之一。

2 依赖倒置原则的意义

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

证明一个定理是否正确，有两种常用的方法：一种是根据提出的论题，经过一番论证，推出和定理相同的结论，这是顺推证法；还有一种是首先假设提出的命题是伪命题，然后推导出一个荒谬、与已知条件互斥的结论，这是反证法。我们今天就用反证法来证明依赖倒置原则是多么优秀和伟大！

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

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

我们通过一个例子来说明反论题是不成立的。现在的汽车越来越便宜了，一个卫生间的造价就可以买到一辆不错的汽车，有汽车就必然有人来驾驶，司机驾驶奔驰车的类图如图3-1所示。

奔驰车可以提供一个方法run，代表车辆运行，实现过程如代码清单3-1所示。

代码清单3-1 司机源代码

public class Driver { 
 //司机的主要职责就是驾驶汽车
 public void drive(Benz benz){
 benz.run();
 }

司机通过调用奔驰车的run方法开动奔驰车，其源代码如代码清单3-2所示。

代码清单3-2 奔驰车源代码

public class Benz {
 //汽车肯定会跑
 public void run(){
 System.out.println("奔驰汽车开始运行...");
 }
}

有车，有司机，在Client场景类产生相应的对象，其源代码如代码清单3-3所示。

代码清单3-3 场景类源代码

public class Client {
 public static void main(String[] args) {
 Driver zhangSan = new Driver();
 Benz benz = new Benz();
 //张三开奔驰车
 zhangSan.drive(benz);
 }
}

通过以上的代码，完成了司机开动奔驰车的场景，到目前为止，这个司机开奔驰车的项目没有任何问题。我们常说“危难时刻见真情”，我们把这句话移植到技术上就成了“变更才显真功夫”，业务需求变更永无休止，技术前进就永无止境，在发生变更时才能发觉我们的设计或程序是否是松耦合。我们在一段貌似磐石的程序上加上一块小石头：张三司机不仅要开奔驰车，还要开宝马车，又该怎么实现呢？麻烦出来了，那好，我们走一步是一步，我们先把宝马车产生出来，实现过程如代码清单3-4所示。

代码清单3-4 宝马车源代码

public class BMW {
 //宝马车当然也可以开动了
 public void run(){
 System.out.println("宝马汽车开始运行...");
 }
}

宝马车也产生了，但是我们却没有办法让张三开动起来，为什么？张三没有开动宝马车的方法呀！一个拿有C驾照的司机竟然只能开奔驰车而不能开宝马车，这也太不合理了！在现实世界都不允许存在这种情况，何况程序还是对现实世界的抽象，我们的设计出现了问题：司机类和奔驰车类之间是紧耦合的关系，其导致的结果就是系统的可维护性大大降低，可读性降低，两个相似的类需要阅读两个文件，你乐意吗？还有稳定性，什么是稳定性？固化的、健壮的才是稳定的，这里只是增加了一个车类就需要修改司机类，这不是稳定性，这是易变性。被依赖者的变更竟然让依赖者来承担修改的成本，这样的依赖关系谁肯承担！证明到这里，我们已经知道反论题已经部分不成立了。

注意 设计是否具备稳定性，只要适当地“松松土”，观察“设计的蓝图”是否还可以茁壮地成长就可以得出结论，稳定性较高的设计，在周围环境频繁变化的时候，依然可以做到“我自岿然不动”。

我们继续证明，“减少并行开发引起的风险”，什么是并行开发的风险？并行开发最大的风险就是风险扩散，本来只是一段程序的错误或异常，逐步波及一个功能，一个模块，甚至到最后毁坏了整个项目。为什么并行开发就有这样的风险呢？一个团队，20个开发人员，各人负责不同的功能模块，甲负责汽车类的建造，乙负责司机类的建造，在甲没有完成的情况下，乙是不能完全地编写代码的，缺少汽车类，编译器根本就不会让你通过！在缺少Benz类的情况下，Driver类能编译吗？更不要说是单元测试了！在这种不使用依赖倒置原则的环境中，所有的开发工作都是“单线程”的，甲做完，乙再做，然后是丙继续……这在20世纪90年代“个人英雄主义”编程模式中还是比较适用的，一个人完成所有的代码工作。但在现在的大中型项目中已经是完全不能胜任了，一个项目是一个团队协作的结果，一个“英雄”再牛也不可能了解所有的业务和所有的技术，要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系，那然后呢？依赖倒置原则就隆重出场了！

根据以上证明，如果不使用依赖倒置原则就会加重类间的耦合性，降低系统的稳定性，增加并行开发引起的风险，降低代码的可读性和可维护性。承接上面的例子，引入依赖倒置原则后的类图如图3-2所示。

建立两个接口：IDriver和ICar，分别定义了司机和汽车的各个职能，司机就是驾驶汽车，必须实现drive()方法，其实现过程如代码清单3-5所示。

public interface IDriver {
 //是司机就应该会驾驶汽车
 public void drive(ICar car);
}

接口只是一个抽象化的概念，是对一类事物的最抽象描述，具体的实现代码由相应的实现类来完成，Driver实现类如代码清单3-6所示

代码清单3-6 司机类的实现

public class Driver implements IDriver{ 
 //司机的主要职责就是驾驶汽车
 public void drive(ICar car){
 car.run();
 }
}

在IDriver中，通过传入ICar接口实现了抽象之间的依赖关系，Driver实现类也传入了ICar接口，至于到底是哪个型号的Car，需要在高层模块中声明。ICar及其两个实现类的实现过程如代码清单3-7所示。

代码清单3-7 汽车接口及两个实现类

public interface ICar {
 //是汽车就应该能跑
public void run();
}
public class Benz implements ICar{
 //汽车肯定会跑
 public void run(){
 System.out.println("奔驰汽车开始运行...");
 }
}
public class BMW implements ICar{ 
 //宝马车当然也可以开动了
 public void run(){
 System.out.println("宝马汽车开始运行...");
 }
}

在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此在高层次的模块中应用都是抽象，Client的实现过程如代码清单3-8所示

代码清单3-8 业务场景

public class Client {
 public static void main(String[] args) {
 IDriver zhangSan = new Driver();
 ICar benz = new Benz();
 //张三开奔驰车
 zhangSan.drive(benz);
 }
}

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

代码清单3-9 张三驾驶宝马车的实现过程

public class Client {
 public static void main(String[] args) {
 IDriver zhangSan = new Driver();
 ICar bmw = new BMW();
 //张三开奔驰车
 zhangSan.drive(bmw);
 }
}

在新增加低层模块时，只修改了业务场景类，也就是高层模块，对其他低层模块如Driver类不需要做任何修改，业务就可以运行，把“变更”引起的风险扩散降到最低。

注意 在Java中，只要定义变量就必然要有类型，一个变量可以有两种类型：表面类型和实际类型，表面类型是在定义的时候赋予的类型，实际类型是对象的类型，如zhangSan的表面类型是IDriver，实际类型是Driver。

我们再来思考依赖倒置对并行开发的影响。两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，而且项目之间的单元测试也可以独立地运行，而TDD（Test-DrivenDevelopment，测试驱动开发）开发模式就是依赖倒置原则的最高级应用。我们继续回顾上面司机驾驶汽车的例子，甲程序员负责IDriver的开发，乙程序员负责ICar的开发，两个开发人员只要制定好了接口就可以独立地开发了，甲开发进度比较快，完成了IDriver以及相关的实现类Driver的开发工作，而乙程序员滞后开发，那甲是否可以进行单

元测试呢？答案是可以，我们引入一个JMock工具，其最基本的功能是根据抽象虚拟一个对象进行测试，测试类如代码清单3-10所示。

代码清单3-10 测试类

public class DriverTest extends TestCase{
 Mockery context = new JUnit4Mockery();
 @Test
 public void testDriver() {
 //根据接口虚拟一个对象
 final ICar car = context.mock(ICar.class);
 IDriver driver = new Driver();
 //内部类
 context.checking(new Expectations(){{
 oneOf (car).run(); 
 }});
 driver.drive(car);
 }
}

注意粗体部分，我们只需要一个ICar的接口，就可以对Driver类进行单元测试。从这一点来看，两个相互依赖的对象可以分别进行开发，孤立地进行单元测试，进而保证并行开发的效率和质量，TDD开发的精髓不就在这里吗？测试驱动开发，先写好单元测试类，然后再写实现类，这对提高代码的质量有非常大的帮助，特别适合研发类项目或在项目成员整体水平比较低的情况下采用。抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，还同时约束自己与外部的关系，其目的是保证所有的细节不脱离契约的范畴，确保约束双方按照既定的契约（抽象）共同发展，只要抽象这根基线在，细节就脱离不了这个圈圈，始终让你的对象做到“言必信，行必果”。

3. 依赖的三种写法

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

对象的依赖关系有三种方式来传递，如下所示。

3.1 构造函数传递依赖对象

在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫做构造函数注入，按照这种方式的注入，IDriver和Driver的程序修改后如代码清单3-11所示。

代码清单3-11 构造函数传递依赖对象

public interface IDriver {
    /**
     * 定义动作
     */
    void drive();
}

public class DriverImpl implements IDriver {
    private IDriver idDriver;

    private IDriver idDriver() {
        return idDriver;
    }

    private void setIdDriver(IDriver idDriver) {
        this.idDriver = idDriver;
    }

    /**构造函数注入*/
    public DriverImpl(IDriver idDriver) {
        setIdDriver(idDriver);
    }

    /**司机的主要职责就是驾驶汽车*/
    @Override
    public void drive() {
        idDriver().drive();
    }
}

3.2 Setter方法传递依赖对象

在抽象中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入，按照这种方式的注入，IDriver和Driver的程序修改后如代码清单3-12所示。

代码清单3-12 Setter依赖注入

public interface IDriver {
    /**
     * 定义动作
     */
    void drive();
    /**
     * 定义车辆类型
     * @param info 车辆信息
     */
    void setCar(IDriver info);
}

public class DriverImpl implements IDriver {
    private IDriver idDriver;
    private IDriver idDriver() {return idDriver;}
    private void setIdDriver(IDriver idDriver) {this.idDriver = idDriver;}
    /**司机的主要职责就是驾驶汽车*/
    @Override
    public void drive() {idDriver().drive();}
    /**
     * 描述车辆的相关信息
     * @param info 车辆信息
     */
    @Override
    public void setCar(IDriver info) {setIdDriver(info);}
}

3.3 接口声明依赖对象

在接口的方法中声明依赖对象，3.2节的例子就采用了接口声明依赖的方式，该方法也叫做接口注入。

4 最佳实践

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

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

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

• 变量的表面类型尽量是接口或者是抽象类

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

• 变量的表面类型尽量是接口或者是抽象类

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

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

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

这种情况尽量发生在不甚了解父类或者无法获得父类代码的情况下。）

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

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

• 结合里氏替换原则使用

在第2章中我们讲解了里氏替换原则，父类出现的地方子类就能出现，再结合本章的讲解，我们可以得出这样一个通俗的规则： 接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。讲了这么多，估计大家对“倒置”这个词还是有点不理解，那到底什么是“倒置”呢？我们先说“正置”是什么意思，依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程，这也是正常人的思维方式，我要开奔驰车就依赖奔驰车，我要使用笔记本电脑就直接依赖笔记本电脑，而编写程序需要的是对现实世界的事物进行抽象，抽象的结果就是有了抽象类和接口，然后我们根据系统设计的需要产生了抽象间的依赖，代替了人们传统思维中的事物间的依赖，“倒置”就是从这里产生的。

---

依赖倒置原则的优点在小型项目中很难体现出来，例如小于10个人月的项目，使用简单的SSH架构，基本上不费太大力气就可以完成，是否采用依赖倒置原则影响不大。但是，在一个大中型项目中，采用依赖倒置原则有非常多的优点，特别是规避一些非技术因素引起的问

题。项目越大，需求变化的概率也越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的，如果设计优良、代码结构清晰，人员变化对项目的影响基本为零。大中型项目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展和维护。

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

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

---

当年汉高祖刘邦入关后与老百姓约法三章，其中有一条就是：“杀人者死，伤人及盗抵罪。”
之，那这里的“杀人”就是一个抽象的含义，怎么杀，杀什么人，为什么杀人，都没有定义，只要是杀人就统统得偿命，这就是有问题了，好人杀了坏人，还要陪上自己的一条性命，这是不公正的，从这一点看，我们在实际的项目中使用依赖倒置原则时需要审时度势，不要抓住一个原则不放，每一个原则的优点都是有限度的，并不是放之四海而皆准的真理，所以别为了遵循一个原则而放弃了一个项目的终极目标：投产上线和盈利。作为一个项目经理或架构师，应该懂得技术只是实现目的的工具，惹恼了顶头上司，设计做得再漂亮，代码写得再完美，项目做得再符合标准，一旦项目亏本，产品投入大于产出，那整体就是扯淡！你自己也别想混得更好！

---

当年汉高祖刘邦入关后与老百姓约法三章，其中有一条就是：“杀人者死，伤人及盗抵罪。”

.依赖倒置原则

1. 定义
   高层模块不应该依赖于底层模块，而应该依赖于抽象。抽象不应依赖于细节，细节应依赖于抽象。
2. 解决的问题
   类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。因此我们需要将依赖的方向进行重新规划，像下面这样：
   
   我们将接口与实现相分离，应用与细节相分离，接口层提供我们业务层所需要的接口方法，实现层对接口的具体方法进行实现，高层业务逻辑不关心接口实现的具体细节，它只对接口进行调用，从而降低了类之间的耦合性，增加了代码的可读性，降低了后续维护的成本。
   实例：
   定义一个武汉店类，该类有个sell（）方法，访问该方法可以显示周黑鸭

class wuhanshop
{
public:
    void sell()
    {
        cout << "zhouheiya" << endl;
    }
};

定义一个顾客类，顾客类中有gouwu（）方法，通过往该方法中传具体的商店来进行购物

class guke
{
public:
    void gouwu(wuhanshop ws)
    {
        ws.sell();
    }
};

下面开始购物

void main()
{
    guke mike;
    wuhanshop ws;
    mike.gouwu(ws);
}

如果此时顾客mike想去其他商店，比如福建商店进行购物买烤老鼠

class fujianshop
{
public:
    void sell()
    {
        cout << "kaolaoshu" << endl;
    }
};

此时main函数换成

void main()
{
    guke mike;
    fujianshop fs;
    mike.gouwu(fs);
}

此时guke类也要修改

class guke
{
public:
    void gouwu(fujianshop fs)
    {
        fs.sell();
    }
};

假如以后需求换成湖南店呢？换成上海店呢？还要不断地修改 guke类，这显然不是好的设计。原因就是 guke类与 具体的shop类 之间的耦合性太高了，必须降低他们之间的耦合度才行。耦合度高的影响就是一旦商店改变，顾客就需要改变。

强耦合关系：任意一方的改变都将导致双方发生改变

因此我们在guke类与具体的shop类中提供一个抽象类shop

#include<iostream>
using namespace std;

class shop
{
public:
    virtual void sell() = 0;
};
class guke
{
public:
    void gouwu(shop* shop)
    {
        shop->sell();
    }
};
class wuhanshop:public shop
{
public:
    void sell()
    {
        cout << "zhouheiya" << endl;
    }
};
class fujianshop :public shop
{
public:
    void sell()
    {
        cout << "kaolaoshu" << endl;
    }
};
void main()
{
    guke mike;
    wuhanshop ws;
    fujianshop fs;
    mike.gouwu(&ws);
    mike.gouwu(&fs);
}

将guke类中的参数设为指向抽象类shop的指针，具体的商店继承该抽象shop，因为父类指针可以指向子类对象，因此在购物时将具体商店子类对象的地址传进去，而不需要改变guke类