Spring学习第二天：Spring_IOC&DI概述

IOC&DI概述

IOC（Inversion of Control）：其思想是反转资源获取的方向。传统的资源查找方式要求组件向容器发起请求查找资源，作为回应，容器适时的返回资源。而应用了IOC之后，则是容器主动地将资源推送给他所管理的组件，组件所要做的仅是选择一种合适的方式来接受资源，这种行为也被称为查找的被动形式。

DI(Dependency Injection)： IOC的另一种表示方式：即组件以一些预先定义好的方式（如：setter方式）接受来自如容器的资源注入，相对于IOC而言，这种表述更直接。

有如下两个类：

class A{}
class B{
private A a;
public void setA(A a){
this.a = a;
}
}

现有如下需求：

从容器中获取 B 对象，并使 B 对象的 a 属性被赋值为容器中 A 对象的引用

UML图如下：



传统的方式：



A a = getA();

B b = getB();

b.setA(a);

使用IOC容器：



容器自动帮我们做好了关联关系，把A对象的引用直接通过set方法给了B对象中a的成员变量。

所以我们只需要获得B对象就可以了。

B b = getB();

这就是IOC容器的效果。

IOC的前生：

IOC的发展可以分为三个阶段

结合如下需求进行分析：生成HTML或PDF格式的不同类型的报表

第一阶段：分离接口和实现



有一个接口ReportGenerator，姑且叫它报表生成器，它有两种方式，一种是Html生成方式，一种是PDF生成方式。

现在有一个报表服务类需要用这个报表生成器。有可能用的是PDF的方式，也有可能用的是Html的方式。

此时最常用的方式是从service中画出三条线，这既需要知道接口类型，也需要知道具体的实现类，而且可能还需要知道如何去创建实现类的对象，这是耦合度最高的一种方式。

就是在说在service中需要知道接口，还需要知道接口的每个实现类的细节。

打个比方：在远古时代，原始人需要一把斧子，他不仅需要知道这把斧子的形状，他还需要知道如何打造一把斧子。这个要求是非常高的。

第二阶段：采用工厂设计模式



现在到了封建社会，我需要一把斧子，我只要带着银子去铁匠铺，让他给我做一把斧子。这个时候耦合度就降低了。

Service只需要画出两条线。一条线是我需要知道接口类型，同时，另一条线指向工厂就可以。这个工厂会帮我生成接口的实现类。

这样在service角度看用起来会更加舒服，但这会导致代码复杂度增加。

于此同时，代码分工更加明确，更有利于扩展，项目也更加灵活。

第三阶段：采用反转控制



到了现在社会，实现了按需分配。我需要什么，你给我什么。

Service只需要画出一条线，由容器把我需要的generator的实现类直接注入给我就可以了。

也就是假设我需要一把斧子，我只需要在院子里面放一个可以装斧子的小框子，就有人会把斧子放在我的框子里。

总结一下：

以前在service中需要一个dao，要么使用new，要么使用工厂方式来获取对象，现在使用依赖注入可以避免这些操作。

其实到目前为止，这一部分光看视频还是感觉云里雾里，打算结合书本进行深入研究。

欢迎大神们指导斧正。