好莱坞原则—Spring的IOC容器

IOC容器的概念，之前在学习SSH的时候，就有接触过。但那时候也仅仅是知道这么个概念，认为它非常难理解。事实上并非它难理解，而是我并没有停下来好好对它总结梳理过。

IOC(Inversion of Control)简单介绍：

控制反转”，并非一种技术。而是一种思想。一种主动提供服务的思想。所谓IOC，就是由Spring负责控制对象的生命周期和对象间的关系，与我们传统的在对象内部直接控制背道而驰。

在传统的程序开发中，完毕一个业务逻辑至少须要两个或两个以上的对象协助完毕。通常一个对象要使用另外一个对象。都是直接在对象内部通过new进行创建对象。由程序主动去创建以来对象。

但这就代表着当前的模块和它所依赖的对象紧紧耦合了。可是其实，我们所须要的仅仅是调用依赖对象提供的某项服务而已。可是想想假设有某种方式让这些服务主动送上来满足我们的需求。我们就不用那么费劲了。IOC也就是这么个简单的道理，主动帮忙创建和注入了依赖对象。例如以下图：

传统程序开发： 主动创建对象—>组装对象

IOC容器：生产线—创建和组装对象，client直接获取

IOC容器的思想事实上非常easy， 就是提供某些服务的一个中介机构，全部的资料都先在这个机构中进行登记。告诉别人你是什么？你须要什么？别人才干给你提供服务，而且也把你做为一种服务提供给其它方。




DI（依赖注入）：



Spring的Ioc容器主要使用DI方式实现的，不须要主动查找，在系统执行过程中，动态的向某个对象提供它所须要的其它对象。比方说类A须要操作数据库，曾经我们总是在类A中编写代码创建一个Connection对象，有了Spring之后。我们仅仅须要告诉Spring。A须要一个Connection。至于这个Connection对象怎样创建？何时创建的？类A不须要关心，在系统执行时,Spring会在适当的时候制造一个Connection对象。像打针一样，注射到类A中。




依赖注入主要是通过反射机制来实现的，在前两篇博客中已经有介绍。同一时候IOC提供了三种依赖注入的方式，各自是构造方法注入、setter方法注入和接口方法注入。



Spring的IOC容器设计思想就跟好莱坞原则一样：Don't call us, we will Call you！

 也就是，你不用找我们，我们会找你！