本文主要是介绍依赖注入原理（）白话文，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
只讲原理，不讲过程。
大多数面向对象编程语言，在调用一个类的时候，先要实例化这个类，生成一个对象。
如果你在写一个类，过程中要调用到很多其它类，甚至这里的其它类，也要“依赖”于更多其它的类，那么可以想象，你要进行多少次实例化。
这就是“依赖”的意思。
依赖注入，全称是“依赖注入到容器”， 容器（IOC容器）是一个设计模式，它也是个对象，你把某个类（不管有多少依赖关系）放入这个容器中，可以“解析”出这个类的实例。
所以依赖注入就是把有依赖关系的类放入容器（IOC容器）中，然后解析出这个类的实例。仅此而已。
假如有一个 船(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模式就是解耦比较全面的设计模式模型
这篇关于依赖注入原理（）白话文的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
