Spring的部分理论知识
控制反转。在Java开发中，IoC意味着将你设计好的类交给系统去控制，而不是在你的类内部控制。这称为控制反转。
IoC的原理：
不创建对象，但是描述创建它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。容器负责将这些联系在一起。其原理是基于OO设计原则的The Holly wood Principle：Don't call us, we'll call you（别找我，我会来找你的）。也就是说，所有的组件都是被动的（Passive），所有的组件初始化和调用都由容器负责。组件处在一个容器当中，由容器负责管理。简单的来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓“控制反转”的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，这就是反转。1)不创建对象，但是描述创建它们的方式
在抽象工厂模式的实现类里，我们并没有创建对象，而是直接获取了一个SpeakerFactory工厂已经生成好了的实例对象，而我们只是向SpeakerFactory工厂的生产实例对象方法描述了具体要创建怎么样的一个实例对象，也就是speakerType参数。
2)所有的组件都是被动的（Passive），所有的组件初始化和调用都由容器负责。组件处在一个容器当中，由容器负责管理。
假设SpeakerFactory工厂是一个“容器”、robot类和people类都是“组件”，让我们看看它是不是符合上面的要求。
所有的robot类和people类，或者说是Speaker模块的action类，它们的初始化和调用，是不是由SpeakerFactory工厂来负责的？它们是不是都处在SpeakerFactory工厂当中，由SpeakerFactory工厂负责管理的？
3)这也就是所谓“控制反转”的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，这就是反转。
现在我们可以回顾一下第一种传统方法和下面两种工厂方法的区别了。
在传统方法中，生成实例对象的控制权是在实现类也就是应用代码中的；而在工厂模式里，控制器就明显被转移了：生成实例对象的控制权已经被工厂类掌握，而应用代码里只负责告诉工厂需要什么样的实例对象，然后就能拿到工厂方法自动送上的生成好的想要的实例对象了！
因此根据我的理解，所谓的IoC其实就是工厂模式的某一个变种，只不过Spring框架把它再发扬光大了，把Factory用泛型再次封装以后真正的容器化，把所有的组件模块的初始化和调用都抽离出来放在了一个XML配置文件里统一管理，然后利用了反射机制来获取实际的实例对象。