文章目录
IOC/DI
IOC全称是Inversion of Control 就是控制反转的意思,DI全称是Dependency Injection就是依赖注入的意思。这俩其实是对同一个原理的不同解释,实际上是一回事。DI注入的方式有Setter注入、构造方法注入和注解注入三种。
在传统的程序中当我们需要通过对象去调用某个类的方法时都是这样,在需要某个对象时new一个对象然后调用它,比如这样:
public class Test{
public void save(){
ManagerObject managerObj= new ManagerObject ();
managerObj.insert();
}
public void remove(){
ManagerObject managerObj= new ManagerObject ();
managerObj.delete();
}
}
然后这么一来如果Test类中有20处使用到了ManagerObject这个方法就需要new20次,如果ManagerObject的方法中还调用了别的类对象,这么一来错综复杂的依赖就会像这样。
从这个代码来看虽然起到了代码逻辑复用,但是却没实现资源复用,每一个链路都创建了同样的对象,造成了极大的资源浪费。本应多个 Controller 复用同一个 Service,多个 Service 复用同一个 DAO。现在变成了一个 Controller创建多个重复的 Service,多个 Service 又创建了多个重复的 DAO,从倒三角变成了正三角。
许多组件只需要实例化一个对象就够了,创建多个没有任何意义。针对对象重复创建的问题,我们自然而然想到了单例模式。只要编写类时都将其写为单例,这样就避免了多例模式造成的资源浪费。但是,引入设计模式必然会带来复杂性,况且还是每一个类都为单例,每一个类都会有相似的代码,其弊端不言自明。而且这样还有个致命的弊端就是假如某个接口的实现类变了,需要再每个调用的地方都改一遍。
简单来讲,总归于这么三大问题:
1、创建了许多重复对象(多例模式),造成大量资源浪费;
2、更换实现类需要改动多个地方;
3、创建和配置组件工作繁杂,给组件调用方带来极大不便。
为了解决这三个问题,Spring做了这么一件事,就是把创建对象的过程交给Spring来维护,用户只需要跟Spring将我需要用什么对象即可,无需关心这个对象的创建过程,依赖的这个对象由Spring注入进来,这个过程就是控制反转和依赖注入。当对象交给Spring容器来管理时,默认是单例的,解决了问题1,然后我们只需要告诉Spring我们需要的对象的名字就可以了不需要关心实现,若要更换实现类,只需更改 Bean 的声明配置,即可达到无感知更换,也就解决了问题2,然后创建和配置都交给Spring来处理,无需每个类都写单例的构造方法,解决了问题3。
public class Test{
@AutoWired
private