Car()

Framework();System.out.println(Cat

init....);}public

Bottom();System.out.println(Framework

init....);}

Tire();System.out.println(Bottom

init....);}

但是这样的程序可维护性太低了,如果接下来有了新的需求,如果需要定制车胎的尺寸怎么办,那就需要new

此时底层的代码改动之后,整个调用链上的代码都需要修改,即程序的耦合度太高了

此时就类似于在打造一辆完整的汽车的时候,如果所有的配件都自己制造,那么当用户的需求发生该改变的时候,就需要自己动手来改

我们尝试换一种思路,我们将轮胎外包出去,即将制造轮胎的任务交给代理工厂,此时即使是轮胎的尺寸改了,我们只需要通知代理工厂,自身是不需要出力的

此时在代码里面的体现就是,不在每个类底下创建下级类,而是改为传递的方式(注入)

因此程序改为:

framework;System.out.println(Car

init..);}public

bottom;System.out.println(Framework

init...);}

}此时类的创建顺序是反的,传统代码是Car控制并创建了Framework,Framework控制并创建了Bottom…依次往下

但是改进后的程序控制权发生了反转,不再是使用方创建并控制依赖对象了,而是将依赖对象注入到当前对象里面,依赖对象的控制权不再是当前类控制了

这样的话,即使是依赖类发生变化,当前类都是不受影响的,这就是控制反转,也是Ioc的实现思想

Ioc容器的优势就很容易看出来了:资源不再由资源的使用方管理,而是由不适用资源的第三方管理

DI,即dependency

表示容器在运行期间,动态的为应用程序提供运行时所依赖的资源,就是依赖注入

实际上,DI和Ioc是从不同的角度描述同一件事情,即通过引入Ioc容器,利用依赖注入的方式,实现对象之间的解耦

在上述的代码里面,DI的过程就是我们通过构造方法将依赖对象注入到使用方中

T04BF