IOC(inversion of control)控制反转
在我们的程序中,要实现某个功能,我们都会用到两个或两个以上的类来协同完成,那么在一个类中,我们就会要有它的合作类的引用,也就是说这个类依赖于别的类,这个合作类的获取,将会有一下几种不同的情况
依赖获取的三种方式:
第一种方式:在person的eat()方法里就把吃的水果写死,从开始就创建对象,
缺点 :1.Person类必须依赖于Apple类,如果Apple类没完成,则编译都不能通过
2.不能再更改,当person想再吃别的水果的时候,无法进行修改
3.很难共享给其他人,只能单独使用
4.person类要对Apple的整个生命周期负责,两个类始终耦合在一起
第二种方式:1.通过使用工程类,间接得到需要的对象
通过使用工程类,程序效果确实得到了改进,但是问题依然存在
缺点:1.每个子类的生成的代码都写死在工厂类里面了,如果要换个子类,则必须更改工厂类中的方法
2.面向接口编程,一般都会使用工厂类,一般每个接口都会对于一个工程类,当项目非常大的时候,则会有非常多的工厂类
第三种方式:只需要在外部传入一个现成的对象给方法调用,不同的实现传入不同的对象即可(感觉这么说就是简单的面向接口的编程的好处,具体优势,请看后面)
在系统中,我们可以用一个外部的容器Container 来统一调配整个系统的运行,将对象的创建和获取提取到外部容器,由外部容器为每个组件提供需要的组建.
例如:
在容器中创建Fruit类对象apple,
将Person类依赖的Fruit对象传递给Person类
将了这么多,那么,到底是控制的什么被反转了呢?
获得依赖对象的方式被反转了.
也就是说
将一个对象如何获取它所依赖的对象这个任务的控制权反转到外部容器中。对象的依赖都是在对象创建时,由负责协调整个系统中各个实体间关系的外部容器提供了。
了解了IOC的基本理念后
剩下的问题就是:怎么样把类中依赖的对象的引用传递给类?(我们把这种将依赖对象的引用传递给类的方式叫做注入)
接下来,我们需要研究,有几种方法,可以把对象注入到类的内部
注入的三种方式:
1. 通过接口注入
这种方式要求我们自己定义的组建类必须实现容器给定的一个接口,然后容器通过这个接口,为我们的组建类注入所依赖的类
缺点:容器对组建的侵入性会很强,实现的组建只能给此容器用了,移植性不强
2. Setter注入
在容器中,通过调用对象的setter()方法,将该对象的依赖传递到类当中
3.构造器注入
通过使用构造器,在类初始化的时候,传入对象的依赖
知道了在容器中可以有三种方式把一个类的对象的依赖传入到这个对象的当中去,但是,这个类的对象我们到底该怎么得到呢?它的依赖又该怎么得到呢?
难道也是在容器中,简单的通过new得到不同的对象,然后进行相互调用吗?
如果是这样的话,那么我们仅仅只是完成了一些基于依赖倒转的代码重构工作而已,并没有真正的体现系统的动态性
那么我们该怎么样才能最大程度的体现系统的动态性? 怎么样才能最大程度的将两个类之间的依赖降低,实现解耦合呢?
我们可以给系统一个XML的配置文件,
在该XML配置文件中,设置每个对象的相应的属性信息(即该类的具体依赖)
然后在系统中,解析XML文件得到一个实体类obj类,obj类保留没一个对象的配置信息
然后根据反射原理,利用解析得到的obj类中信息,动态的生成配置对应的对象,并且调用对象的setter()方法,完成对该对象的注入,
因为XML只是一个符合一定格式要求的文本文件,
所以我们可以随时更改XML文件,而不修改源代码
来得到我们需要的任何类型的任何一个对象,并完全对该对象的注入
使该对象的依赖得以进行,并能使系统最大程度的动态化,具有可拓展性
IoC核心理念:
1.在类当中不创建对象,在代码中不直接与对象和服务连接
2.在配置文件中描述创建对象的方式,以及各个组件之间的联系
3.外部容器通过解析配置文件,通过反射来将这些联系在一起
The Hollywood principle:Don’t call us,we’ll call you.
即,所有组件都是被动的、不主动联系(调用)外部代码,
要等着外部代码的调用--------所有的组件的初始化和相互调用都由容器负责实现。
简单的说,就是整个程序之间的关系,都由容器来控制:将程序的控制权反转给容器,就是所谓的外转
而在我们传统代码中,由程序代码直接控制