理解依赖注入（Dependency Injection）

理解依赖注入（Dependency Injection）

控制反转（Inversion of Control，IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency Injection，DI），还有一种方式叫“依赖查找”（Dependency Lookup）。通过控制反转，对象在被创建的时候，由一个调控系统内所有的外界实体将其所依赖的对象的引用传递给它。也可以说，依赖被注入到对象中。

 

依赖注入是目前很多优秀框架都在使用的一个设计模式。Java的开发框架如Spring在用，PHP的Laravel/Phalcon/Symfony等也在用。好多不同语言的框架，设计思想大同小异，相互借鉴参考。熟悉了一个语言的开发框架，其它不同的框架甚至不同语言的开发框架，往往也很容易从设计理念和概念上理解。不过，有些语言因为设计特色，一些设计模式反而看似消失不见了。其实是融入了语言里面，不易察觉。我看见过这么一句话：“设计模式是编程语言固有缺陷的产物”。有一个讨论在这里：Why is IoC / DI not common in Python?

Dependency Injection 常常简称为：DI。它是实现控制反转（Inversion of Control – IoC）的一个模式。有一本依赖注入详解的书在这里:Dependency Injection 。它的本质目的是解耦，保持软件组件之间的松散耦合，为设计开发带来灵活性。

注：IoC不是一种技术，而是一种思想，一个重要的面向对象编程的法则，它能指导我们设计出松耦合、更优良的程序。

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

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

IoC的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象。这一点是通过DI（Dependency Injection，依赖注入）来实现的。比如对象A需要操作数据库，以前我们总是要在A中自己编写代码来获得一个Connection对象，有了 spring我们就只需要告诉spring，A中需要一个Connection，至于这个Connection怎么构造，何时构造，A不需要知道。在系统运行时，spring会在适当的时候制造一个Connection，然后像打针一样，注射到A当中，这样就完成了对各个对象之间关系的控制。A需要依赖 Connection才能正常运行，而这个Connection是由spring注入到A中的，依赖注入的名字就这么来的。那么DI是如何实现的呢？ Java 1.3之后一个重要特征是反射（reflection），它允许程序在运行的时候动态的生成对象、执行对象的方法、改变对象的属性，spring就是通过反射来实现注入的。

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

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

• 谁依赖于谁：当然是应用程序依赖于IoC容器；
• 为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；
• 谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；
• 注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

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

【例子】

假设有一个需求，类Business需要调用类Dependency的方法f()，按照日常的做法，得到下面的代码：

//**类Dependency**
public class Dependency {
    public void f() {};
}

//**类Business**
public class Business {
    Dependency d;
    public Business() {
    d = new Dependency();
    }
    public void doSth() {
        d.f();
    }
}

对上述实现做出如下修改：
首先，将Business里的Dependency实例的获得改为setter方式，其次，将Dependency类改为某个接口的实现。故可以得到下面新的代码：

//**接口IDependency**
public interface IDependency {
    void f();
}

//**类Dependency**
public class Dependency implements IDependency{
    public void f() {};
}

//**类Business**
public class Business {
    IDependency d;
    public Business() {}
    public void doSth() {
        d.f();
    }
    public void setDependency(IDependency d) {
        this.d = d;
    }
}

在新的代码中，首先Business的变量d可以接收任何IDependency的实例，另外，Dependency的实例不是通过Business来获得，而是通过setter(也可以用构造器)来由外部传给它。这似乎跟我们往常的代码没什么不同，但这已经是一个良好的设计。关键就是Dependency的实例如何从外部注入给Business呢？

这就要通过xml来实现了。

可以在applicationContext.xml等类似配置文件中配置，也可以新创建一个配置文件。

创建一个SpringFirst.xml，进行简单的配置：

这个配置文件里将Dependency类和Business类加入，并将Dependency作为Business的一个参数。

单有了这个xml文件还不够，还需要一个测试类来加载该xml文件，spring提供了现成的API，在加载上面的xml的时候，就进行了如下工作：实例化Dependency类，实例化Business类，并将Dependency的实例作为参数赋给了Business实例的
setDependency()方法。下面是该测试程序：

public class StartServer {
    public static void main(String [] args) {
     ClassPathResource cr = new ClassPathResource("SpringFirst.xml");
     BeanFactory factory = new XmlBeanFactory(cr);
     Business b = (Business)factory.getBean("business");
     b.doSth();
    }
}

 

上面的程序加载了xml以后，获得id为"business"的bean，即Business类的实例，并调用了其doSth()方法。由此可见，Business的依赖类Dependency是通过xml来注入的，而且Business是通过接口IDependency来接收Dependency实例。因此，当我们又有新的IDependency的实现时，只需要修改xml文件即可，测试程序只需要根据xml里的id值来获得需要的参数。

总结上面的例子，对控制反转和依赖注入已经能理解了。依赖类(Dependency)是通过外部(xml)来注入的，而不是由使用它的类(Business)来自己制造，这就是依赖的注入。另一方面，Business对类Dependency的依赖转移到对接口IDependency的依赖，控制权由类转移到了接口，即由"实现"转移到"抽象"中。这就是控制反转。

 

参考链接：https://blog.csdn.net/wangfangxu17/article/details/84762405?utm_source=bbsseo