关于IOC,首先了解下spring中的IOC:Spring中IoC的入门实例 http://dev.yesky.com/400/2508400.shtml
Inversion of Control,控制反转英文缩写为IoC。
IoC: Inversion of Control,控制反转, 控制权从应用程序转移到框架(如IoC容器),是框架共有特性
1、为什么需要IoC容器
1.1、应用程序主动控制对象的实例化及依赖装配
- A a = new AImpl();
- B b = new BImpl();
- a.setB(b);
缺点:更换实现需要重新编译源代码
很难更换实现、难于测试
- A a = AFactory.createA();
- B b = BFactory.createB();
- a.setB(b);
本质:创建对象,被动实例化,间接获取依赖,主动装配 (简单工厂)
缺点:更换实现需要重新编译源代码
很难更换实现、难于测试
- A a = Factory.create(“a”);
- B b = Factory.create(“b”);
- a.setB(b);
<!—配置.properties-->
- a=AImpl
- b=BImpl
本质:创建对象,被动实例化,间接获取依赖, 主动装配
(工厂+反射+properties配置文件、
缺点:冗余的依赖装配逻辑
我想直接:
//返回装配好的a
- A a = Factory.create(“a”);
1.2、可配置通用工厂:工厂主动控制,应用程序被动接受,控制权从应用程序转移到工厂
- //返回装配好的a
- A a = Factory.create(“a”);
- <bean id=“a” class=“AImpl”>
- <property name=“b” ref=“b”/>
- </bean>
- <bean id=“b” class=“BImpl”/>
被动实例化,被动接受依赖,被动装配
(工厂+反射+xml配置文件)
缺点:不通用
步骤:
1、读取配置文件根据配置文件通过反射
创建AImpl
2、发现A需要一个类型为B的属性b
3、到工厂中找名为b的对象,发现没有,读取
配置文件通过反射创建BImpl
4、将b对象装配到a对象的b属性上
【组件的配置与使用分离开(解耦、更改实现无需修改源代码、易于更好实现) 】
1.3、 IoC(控制反转)容器:容器主动控制
- //返回装配好的a
- A a = ApplicationContext.getBean(“a”);
- <bean id=“a” class=“AImpl”>
- <property name=“b” ref=“b”/>
- </bean>
- <bean id=“b” class=“BImpl”/>
本质:创建对象和装配对象、管理对象生命周期
被动实例化,被动接受依赖,被动装配
(工厂+反射+xml配置文件)
通用

IoC容器:实现了IoC思想的容器就是IoC容器
2、IoC容器特点
【1】无需主动new对象;而是描述对象应该如何被创建即可
IoC容器帮你创建,即被动实例化;
【2】不需要主动装配对象之间的依赖关系,而是描述需要哪个服务(组件),
IoC容器会帮你装配(即负责将它们关联在一起),被动接受装配;
【3】主动变被动,好莱坞法则:别打电话给我们,我们会打给你;
【4】迪米特法则(最少知识原则):不知道依赖的具体实现,只知道需要提供某类服务的对象(面向抽象编程),松散耦合,一个对象应当对其他对象有尽可能少的了解,不和陌生人(实现)说话
【5】IoC是一种让服务消费者不直接依赖于服务提供者的组件设计方式,是一种减少类与类之间依赖的设计原则。
3、理解IoC容器问题关键:控制的哪些方面被反转了?
1、谁控制谁?为什么叫反转? ------ IoC容器控制,而以前是应用程序控制,所以叫反转
2、控制什么? ------ 控制应用程序所需要的资源(对象、文件……)
3、为什么控制? ------ 解耦组件之间的关系
4、控制的哪些方面被反转了? ------ 程序的控制权发生了反转:从应用程序转移到了IoC容器。
思考:
1: IoC/DI等同于工厂吗?
2: IoC/DI跟以前的方式有什么不一样?
领会:主从换位的思想
上面文章转自:http://jinnianshilongnian.iteye.com/blog/1471944
用PHP实现简单的控制反转(IOC) 依赖注入(DI),用JSON配置文件