怎么理解依赖注入

作者：anderson93
链接：https://www.zhihu.com/question/32108444/answer/121881566

假如有一个 船(C)类 ，一个 桨(J) 类,

class C{
  J j = new J() ;
}

如果船要干什么事，肯定需要浆的参与。所以是十分 “依赖”浆；
出了需求需要重构：这时候我们需要控制浆的长度为10在构造方法中。我们需要这么写；

class C{
  J j = new J(10) ;
}

一个特性需要修改浆构造方法，又需要修改船其中的new J()方法。这时候就设计者就思考，为什么我们加入一个特性需要更改两个类中代码（这也就是耦合度高）！
所以我们要解耦要依赖注入；

常用解耦方式：

• 构造方法注入

如下：我重构代码的时候在也不用看哪里的浆还是短的了！因为船构造方法依赖了浆。任你浆怎么设计，我用的时候传一个浆进来即可。（下层依赖上层，用的时候传入，而不是针对下层去修改）

class C{
  J j 
  public c（J j）{
 this.j = j;
};
}

• 工厂模式注入

工厂模式 Human 人 去注入; 工厂类如下

Class Human {
     J j =new J（）;
   J getJ（）{
      return j ;
}
}

此时如下：不管你怎么改浆，改成100米与船都无关，他只要依赖Human,
一千个船修改浆需求我只修改Human类中方法便可。（核心业务逻辑需要依赖的类实例化交给第三方类来实现注入。）

Class C {
  J j ;
Human h = new Human；
    j=Human.getJ();
}

• 框架注入（本质还是工厂设计模式的具体实现）

本质也是第三方依赖注入，但是这个第三方可以脱离类。将对象依赖映射信息存储在容器一般为.xml 或者特定的对象中，并实现动态的注入。你需要我就给你哦。

为什么要有依赖注入（一种设计代码模式），因为我们要控制反转（设计代码的思路）。为什么控制反转。因为我们软件设计需要符合软件设计原则依赖倒置（设计代码原则），单一职责原则。
说通俗点，咱们要解耦啊。
MVP模式就是解耦比较全面的设计模式模型

---

依赖注入（DI）和控制反转（IOC）基本是一个意思，因为说起来谁都离不开谁。

简单来说，a依赖b，但a不控制b的创建和销毁，仅使用b，那么b的控制权交给a之外处理，这叫控制反转（IOC），而a要依赖b，必然要使用b的instance，那么

1. 通过a的接口，把b传入；
2. 通过a的构造，把b传入；
3. 通过设置a的属性，把b传入；

这个过程叫依赖注入（DI）。

 

那么什么是IOC Container？

随着DI的频繁使用，要实现IOC，会有很多重复代码，甚至随着技术的发展，有更多新的实现方法和方案，那么有人就把这些实现IOC的代码打包成组件或框架，来避免人们重复造轮子。

所以实现IOC的组件或者框架，我们可以叫它IOC Container。