依赖注入

在采用面向对象方法设计方法设计软件系统中，底层实现都是由多个对象组成，对象通过彼此合作，最终实现系统的业务逻辑。

齿轮组中齿轮之间的啮合关系，与软件系统中对象之间的耦合关系非常类似。对象之间的耦合关系是无法避免的，也是必要的，这是协同工作的基础。伴随着工业级应用的规模越来越庞大，对象之间的依赖关系也越来越复杂，经常出现对象之间的多重依赖性关系。因此，架构师和设计师对于系统的分析和设计，面临更大挑战。对象之间耦合度过高的系统，必然出现牵一发而动全身的情形。

耦合关系不仅会出现在对象与对象之间，也会出现在软件系统的各个模块之间，以及软件系统和硬件系统中。如何降低系统之间、模块之间、对象之间的耦合度，是软件工程追求的目标之一。为了解决对象之间的耦合度过高的问题，软件专家Michael Mattson提出IoC理论，用来实现对象之间的解耦。

控制反转

控制反转(Inversion of Control, IoC)是Michael Mattson于1996年在一篇探讨面向对象框架的文章中提出的。对于面向对象设计及编程的基本思想，简单来说就是把复杂系统分解为相互合作的对象，对象类通过封装后，内部实现对外部是透明的，从而降低解决问题的复杂度，灵活地重用和扩展。IoC观点大体是借助于第三方实现（IoC容器）具有依赖关系的对象之间的解耦。

依赖注入是一种软件设计模式的一个或多个依赖注入（或服务），或通过引用传递，为依赖对象（或客户）和客户端状态的一部分。模式之间建立一个客户的依赖关系的行为。依赖注入允许程序设计时松散耦合的，依赖倒置和单一职责原则。依赖注入直接对比Service Locator模式，它允许客户了解他们所使用的系统找到依赖。

借助于第三方，全部对象的控制权全部上缴给IoC容器。所以IoC是整个系统的关键核心，起到类似“粘合剂”的作用。如果没有粘合剂，对象与对象之间会彼此失去联系。

软件系统引入IoC容器之前，对象之间是存在依赖的，例如对象A在初始化或运行到某一点的时候，必须主动创建对象B或使用已经创建的对象B，无论是创建还是使用对象B，控制权都在自己手上。

软件系统引入IoC容器之后，对象之间失去直接联系。当对象A运行需要对象B时，IoC容器会主动创建一个对象B注入到对象A需要的位置。

通过前后对比发现，对象A获得依赖对象B的过程，由主动行为变为被动行为，控制权颠倒了过来，这也就是控制反转名称的由来。

依赖倒置

耦合关系就是依赖关系，如果依赖关系相当复杂，牵一发而动全身将难以维护。依赖关系越少，耦合关系越低，系统就越稳定。

Robert Martin提出面向对象设计原则 - 依赖倒置原则（DIP）

• 上层模块不应该依赖于下层模块，他们共同依赖于一个抽象。
  上层作为使用者，下层作为被使用者，导致的结果是上层依赖下层。下层变动自然会影响上层，导致系统不稳定。如何减少依赖呢？上层和下层都去依赖另一个抽象，只要抽象稳定，整体就比较稳定。
• 抽象不能依赖于具象，具象依赖于抽象。
  面向对象编程是面向抽象或面向接口的编程，抽象一般比较稳定，实现抽象的具象肯定是要依赖于抽象的，抽象不应该去依赖别的具体，应该依赖抽象。

依赖注入

2004年Martin Fowler探讨了同一个问题，既然IoC是控制反转，那么到底是“哪些方面的控制被反转了呢？”。经过详细分析论证，答案是“获得依赖对象的过程被反转了”。控制被反转后，获得依赖对象的过程由自身管理变为由IoC容器主动注入。于是，他给控制反转去了一个更格式的名字叫做依赖注入（Dependency Injection，DI）。依赖注入实际上给出了实现IoC的方法即注入。所谓注入，就是由IoC容器在运行期间，动态地将某种依赖关系注入到对象之中。所以，DI和IoC是从不同的角度描述同一件事务。

通过引入IoC容器，利用依赖关系注入的方式，实现对象之间的解耦。

对象A依赖于对象B，当对象A需要对象B时，IoC容器立即创建一个对象B传给对象A。IoC容器就是一个对象制造工厂，你需要什么，它会给你送去，你不用去关系东西是如何制成的，也不用关心最后是怎样被销毁的。

反射编程

IoC中最基本的技术就是反射（Reflection），通俗来讲就是根据给出的字符串方式的类名，动态地生成对象。这种方式可以让对象在生成时决定到底是哪一种对象。

可以把IoC容器的工作模式看做是工厂模式的升华，将IoC容器看做是一个工厂。工厂要生成的对象都在配置文件中给出定义，利用反射编程，将配置文件中给出的类名生成相应的对象。从实现来看，IoC是把以前在工厂方法中写死的对象生成代码，改变成由配置文件来定义，也就是把工厂和对象生成这两者独立分离开来，目的是提高灵活性和可维护性。