控制反转（IoC）学习笔记

什么是依赖（Dependency）？

依赖是一种关系，通俗来讲就是一种需要。

程序员需要电脑，因为没有电脑程序员就没有办法编写代码，所以说程序员依赖电脑，电脑被程序员依赖。

在面向对象编程中，代码可以这样编写。

class Coder {
    // 程序员依赖电脑，并自己new一个
    Computer mComputer;
    public Coder () {
        mComputer = new Computer();
        // 使用电脑敲代码
        mComputer.coding();
    }
}

但是这里有一个问题，程序员只是需要用电脑敲代码而已，但是却做了两件事

1. 造一台电脑
2. 用这台电脑敲代码

还导致另一个问题，假如程序员要出门，想要带一个笔记本出门。那么还要重新造（new）一台笔记本。

class Coder {
    // 自己造个笔记本
    Laptop mLaptop;
    public Coder () {
        mLaptop= new Laptop();
        // 使用笔记本敲代码
        mComputer.coding();
    }
}

针对上面出现的问题，下面会给出解答。

依赖倒置 (Dependency inversion principle)

什么是依赖倒置？

依赖倒置是面向对象设计领域的一种软件设计原则。

什么是设计原则？ 

设计原则是前辈们总结出来的经验，你可以把它们看作是内功心法。

软件设计有5大设计原则，合称 SOLID。

依赖倒置原则的定义如下：

1. 上层模块不应该依赖底层模块，它们都应该依赖于抽象。
2. 抽象不应该依赖于细节，细节应该依赖于抽象。

乍一看，这会让初学者摸不清头脑。这种学术性的概括语言近乎于软件行业中的哲学。可实质上，它确实称得上是哲学，现在 SOLID 几乎等同于面向对象开发中的金科玉律，但是也正因为它的高度概括、它的晦涩难懂，对于广大初学者而言这是一件非常不友好的事物。

什么是上层模块和底层模块？

对于任何一个组织机构而言，它一定有架构的设计有职能的划分。按照职能的重要性，自然而然就有了上下之分。

公司管理层就是上层，CEO 是整个事业群的上层，那么 CEO 职能之下就是底层。

然后，我们再以事业群为整个体系划分模块，各个部门经理以上部分是上层，那么之下的组织都可以称为底层。由此，我们可以看到，在一个特定体系中，上层模块与底层模块可以按照决策能力高低为准绳进行划分。

什么是抽象和细节？

抽象如其名字一样，是一件很抽象的事物。抽象往往是相对于具体而言的，具体也可以被称为细节，当然也被称为具象。

比如： 
1. 这是一幅画。画是抽象，而油画、素描、国画而言就是具体。 
2. 这是一件艺术品，艺术品是抽象，而画、照片、瓷器等等就是具体了。 
3. 交通工具是抽象，而公交车、单车、火车等就是具体了。 
4. 表演是抽象，而唱歌、跳舞、小品等就是具体。

上面可以知道，抽象可以是物也可以是行为。

具体映射到软件开发中，抽象可以是接口或者抽象类形式。

public interface Driveable {
    void drive();
}
class Bike implements Driveable{
    @Override
    public void drive() {
        System.out.println("Bike drive.");
    }
}
class Car implements Driveable{
    @Override
    public void drive() {
        System.out.println("Car drive.");
    }
}

Driveable 是接口，所以它是抽象，而 Bike 和 Car 实现了接口，它们被称为具体。

依赖倒置的好处

在平常的开发中，我们大概都会这样编码。

public class Person {
    private Bike mBike;
    public Person() {
        mBike = new Bike();
    }
    public void chumen() {
        System.out.println("出门了");
        mBike.drive();
    }
}

我们创建了一个 Person 类，它拥有一台自行车，出门的时候就骑自行车。

public class Test1 {
    public static void main(String[] args) {
        Person person = new Person();
        person.chumen();
    }
}

不过，自行车适应很短的距离。如果，我要出门逛街呢？自行车就不大合适了。于是就要改成汽车。

我们需要修改 Person 这个类的代码。

public class Person {
    //private Bike mBike;
    private Car mCar;
    public Person() {
        //mBike = new Bike();
        mCar = new Car();
    }
    public void chumen() {
        System.out.println("出门了");
        //mBike.drive();
        mCar.drive();
    }
}

不过，如果我要到北京去，那么汽车也不合适了。

class Train implements Driveable{
    @Override
    public void drive() {
        System.out.println("Train drive.");
    }
}

public class Person {
    //private Bike mBike;
    //private Car mCar;
    private Train mTrain;
    public Person() {
        //mBike = new Bike();
        //mCar = new Car();
        mTrain = new Train();
    }
    public void chumen() {
        System.out.println("出门了");
        //mBike.drive();
        //mCar.drive();
        mTrain.drive();
    }
}

我们添加了 Train 这个最新的实现类，然后再次修改了 Person 这个类。

有没有一种方法能让 Person 的变动少一点呢？因为这是最基础的演示代码，如果工程大了，代码复杂了，Person 面对需求变动时改动的地方会更多。

而依赖倒置原则正好适用于解决这类情况。

下面，我们尝试运用依赖倒置原则对代码进行改造。

我们再次回顾下它的定义。

1. 上层模块不应该依赖底层模块，它们都应该依赖于抽象。
2. 抽象不应该依赖于细节，细节应该依赖于抽象。

首先是上层模块和底层模块的拆分。

按照决策能力高低或者重要性划分，Person 属于上层模块，Bike、Car 和 Train 属于底层模块。

上层模块不应该依赖于底层模块。 
但是

public class Person {
    //private Bike mBike;
    //private Car mCar;
    private Train mTrain;
    public Person() {
        //mBike = new Bike();
        //mCar = new Car();
        mTrain = new Train();
    }
}

Person 这个类显然是依赖于 Bike 和 Car。Person 类中 chumen() 的能力完全依赖于属性 Bike 或者 Car 对象，也就是说 Person 把自己的能力依赖在 Bike 和 Car 身上。

用图来表示就是这样的，Person直接依赖于Bike、Car和Train

上层和底层都应该依赖于抽象。我们的代码中，Person 没有依赖抽象，所以我们得引进抽象。

而底层的抽象是什么，是 Driveable 这个接口。

public class Person {
//  private Bike mBike;
//  private Car mCar;
//  private Train mTrain;
    private Driveable mDriveable;

    public Person() {
        //mBike = new Bike();
        //mCar = new Car();
        //mTrain = new Train();
        mDriveable = new Train();
    }

    public void chumen() {
        System.out.println("出门了");
        //mBike.drive();
        //mCar.drive();
        //mTrain.drive();
        mDriveable.drive();
    }
}

现在，Person 类中 chumen() 这个方法依赖于 Driveable 接口的抽象，它没有限定自己出行的可能性，任何 Car、Bike 或者是 Train 都可以的。

到这一步，我们可以说是符合了上层不依赖于底层，依赖于抽象的准则了。

那么，抽象不应该依赖于细节，细节应该依赖于抽象又是什么意思呢？

以上面为例，Driveable 是抽象，它代表一种行为，而 Bike、Car、Train 都是实现细节。

Person 需要的是 Driveable，需要的是交通工具，但不是说交通工具一定是 Bike、Car、Train。未来也可能是 AirPlane。

class AirPlane implements Driveable {
    @Override
    public void drive() {
        System.out.println("AirPlane fly.");
    }
}

那么一个 Person，它下次出门改成飞机可以吗？当然可以的。因为依赖倒置的缘由，Person 展现出了极度的可扩展性。

所以引入抽象这个概念之后，画成图就是这样的。

上面的内容就是依赖倒置原则。

本来常规编码下，肯定会出现上层依赖底层的情况。

而依赖倒置原则的应用则改变了它们之间依赖的关系，它引进了抽象。上层依赖于抽象，底层的实现细节也依赖于抽象，所以依赖倒置我们可以理解为依赖关系被改变，如果非常纠结于倒置这个词，那么倒置的其实是底层细节，原本它是被上层依赖，现在它倒要依赖与抽象的接口。

可以看到，依赖倒置实质上是面向接口编程的体现。

控制反转 （IoC）

控制反转 IoC 是 Inversion of Control的缩写，意思就是对于控制权的反转，对么控制权是什么控制权呢？ 
大家重新审视上面的代码。

public class Person {
//  private Bike mBike;
//  private Car mCar;
//  private Train mTrain;
    private Driveable mDriveable;
    public Person() {
        //mBike = new Bike();
        //mCar = new Car();
        //mTrain = new Train();
        mDriveable = new Train();
    }
    public void chumen() {
        System.out.println("出门了");
        //mBike.drive();
        //mCar.drive();
        //mTrain.drive();
        mDriveable.drive();
    }
}

虽然，chumen() 这个方法不再因为出行方式的改变而变动，但是每次更改出行方式的时候，Person 这个类还是要修改。

Person 类还是要实例化 mDriveable 的接口对象。

这里人的工作是 drive（驾驶），而不是造车。在之前的方法中每一次想要开车，这个人还必须要亲自造（new）一辆车出来。而且每次驾驶不同的交通工具，就要造（new）出相应的交通工具。耦合性太严重，无法专注自己的功能。

Person 自己掌控着内部 mDriveable 的实例化。 
现在，我们可以更改一种方式。将 mDriveable 的实例化移到 Person 外面。

public class Person {
    private Driveable mDriveable;
    // 构造器注入
    public Person(Driveable driveable) {
        this.mDriveable = driveable;
    }
    public void chumen() {
        System.out.println("出门了");
        mDriveable.drive();
    }
}

就这样无论出行方式怎么变化，Person 这个类都不需要更改代码了

换句话说Person与交通工具类已经解耦了，现在Person只需要关注自己的功能（chumen），不必自己造（new）车开了。

public class Test1 {
    public static void main(String[] args) {
        Bike bike = new Bike();
        Car car = new Car();
        Train train = new Train();
//      Person person = new Person(bike);
//      Person person = new Person(car);
        Person person = new Person(train);

        person.chumen();
    }
}

在上面代码中，交通工具的创建不是在Person类里面了，而是在Test1类里面。

反转了什么？

有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。

这里引入新的概念，IoC容器

这里我们把创建对象的任务交给了Test1这个类，然后把Test1创建的对象注入进Person类中，这里Test1 在 IoC 中就充当了 IoC 容器 这个角色。而在Spring中，创建对象的任务交给了Spring 的IoC容器.

下面又要引入一个新的概念，依赖注入（DI）

下面我们着重看一下上面出现的这个代码

public class Person {
    private Driveable mDriveable;
    // 构造器注入
    public Person(Driveable driveable) {
        this.mDriveable = driveable;
    }
    public void chumen() {
        System.out.println("出门了");
        mDriveable.drive();
    }
}

主要观察，这里已经没有了new这个关键字，取而代之的是构造函数多了个参数。

这就是依赖注入（Dependency injection），对象是被【注入】进来的，而不是自己new出来的。这里也就解释了控制反转（IoC）和依赖注入的关系（DI）。

控制反转是种设计思想，而依赖注入是他的实现方式。

那么问题又来了，在Spring中依赖注入的方式有几种呢？

常见的有X种，上面用到的是构造器注入

实现依赖注入有 3 种方式： 

1. 构造函数中注入 
2. setter 方式注入 
3. 注解注入（@Autowire）

我们现在一一观察这些方式

构造函数注入

public class Person {
    private Driveable mDriveable;
    public Person(Driveable driveable) {
        this.mDriveable = driveable;
    }
    public void chumen() {
        System.out.println("出门了");
        mDriveable.drive();
    }
}

• 优点：在 Person 一开始创建的时候就确定好了依赖。 
• 缺点：后期无法更改依赖。

setter 方式注入

public class Person {
    private Driveable mDriveable;
    public Person() {
    }
    public void chumen() {
        System.out.println("出门了");
        mDriveable.drive();
    }
    public void setDriveable(Driveable mDriveable) {
        this.mDriveable = mDriveable;
    }
}

• 优点：Person 对象在运行过程中可以灵活地更改依赖。 
• 缺点：Person 对象运行时，可能会存在依赖项为 null 的情况，所以需要检测依赖项的状态。

public void chumen() {
    if ( mDriveable != null ) {
        System.out.println("出门了");
        mDriveable.drive();
    }
}

注解注入

后面详细讲

常见问题

IoC是什么

　　Ioc—Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想。在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。如何理解好Ioc呢？理解好Ioc的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”，那我们来深入分析一下：

　　●谁控制谁，控制什么：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对 象的创建；谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。

　　●为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。

IoC能做什么

　　IoC 不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是 松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。

　　其实IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。

　　IoC很好的体现了面向对象设计法则之一—— 好莱坞法则：“别找我们，我们找你”；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。

IoC和DI

　　DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。

　　理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：

　　●谁依赖于谁：当然是应用程序依赖于IoC容器；

　　●为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；

　　●谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；

　　●注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

　　IoC和DI由什么关系呢？其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。

总结

1. 依赖倒置是面向对象开发领域中的软件设计原则，它倡导上层模块不依赖于底层模块，抽象不依赖细节。
2. 控制反转是遵守依赖倒置这个原则而提出来的一种设计模式，它引入了 IoC 容器的概念。
3. 依赖注入是为了实现控制反转的一种手段之一。
4. 它们的本质是为了代码更加的“高内聚,低耦合”。

参考：

https://blog.csdn.net/briblue/article/details/75093382

https://www.zhihu.com/question/23277575

http://www.cnblogs.com/xdp-gacl/p/4249939.html

https://juejin.im/post/5b040cf66fb9a07ab7748c8b