早上起来占个坑,晚上整理。
依赖注入DI(dependency injection):
谁依赖谁?谁注入谁?注入什么?
调用类依赖功能类。
容器注入调用类。
注入了功能类的实例。
控制反转Ioc(inversion of control):
谁控制谁?反转了什么?正转是什么?
ioc容器控制实例的创建和管理、注入。
反转了实例的创建方,由调用类转移到Ioc容器中。
正转是在调用类中主动创建功能类的实例,控制它的生命周期。
依赖注入和控制反转的区别?
依赖注入和控制反转不是一门技术,而是一种通过注入依赖对象来实现解耦的设计思想,是程序设计的一个基本设计原则。
所以,对它们没有明确的技术界限的定义,仁者见仁智者见智,各自有各自的理解。重点是其中的注入依赖对象的解耦思想。
这种设计原则,设计思想初期从控制权的角度称作Ioc,但2004年一个技术大牛认为控制反转不太贴切,提出了依赖注入这个概念。其实无论依赖注入还是控制反转,他们只是对同一设计思想,在不同方面理解下的称呼而已,并无实质区别。
spring 的Ioc容器在这一设计原则下做了什么?
将调用类所有依赖的对象通过注入的方式赋予调用类,实现了最大程度的解耦合(调用类只需认识功能类的接口和Ioc容器)。
但是这样虽然不必再让调用类去认识所有的ICar的实际类,只需要认识一个ICar接口,降低了耦合度,但产生了一个问题,
创建一个Person实例时,我还需要创建一个ICar的实例,然后手动注入Person实例,如果Person类还依赖于许多类,那么当创建一个Person实例就需要同时创建许多个功能类实例,然后再手动注入Person中,这样太累了,,,
而我又想用这种设计方法来降低我的代码耦合度,又不想创建一个实例这么麻烦地做这么多工作,怎么办呢,,,
spring Ioc登场,框架就是来为开发者省时省力的(学框架虽然麻烦,但学会它会给你省去更多的麻烦,超值!!!安慰自己)
通过spring Ioc容器,我们只需在Beans中配置类的实例化参数,和他们之间的依赖关系,就可以像传统地开发方式一样轻松地创建类地实例对象了
ApplicationContext context=new ClassPathXmlApplicationContext();
Person p1=context.getBean("p1");//通过id创建
Person p2=context.getBean(Person.class);//通过类型创建
关于如何通过配置,选择不同的初始化方法,注入类的属性参数、依赖对象,可以通过进一步学习掌握啦。
(其实想想spring Ioc的容器管理和mybatis的sql管理相似,先配置xml文件、创建框架的工厂,工厂通过id或其他参数调用具体实例,核心思想很相似。看得多了大致都是这样)
所以,:
依赖注入和控制反转只是对这同一种设计原则的不同称呼,搞明白这种设计思想的原理、用处、优点、精妙之处后,
其明确,界限分明的定义如何阐述就不重要了,在你心中就有了自己的一套解释。