spring核心之设计原理总结

本文采用问题探究的方式来加深对spring的架构和设计原理的理解，探究的问题如下：

• 为什么要使用spring ioc容器？spring ioc容器和工厂模式的比较？
• spring有什么样的设计目标？从而采用了什么设计理念？

为什么要使用spring ioc容器

在没有引入ioc容器和对象工厂时，我们遇到的问题是：要在对象的使用者模块中创建对象，并管理对象依赖的属性。这样做最大的问题是被调用的对象出现在使用者的代码里，使得对象的使用者和对象的耦合程度很高。同时，对象难以重用，难以细粒度地控制组装对象的依赖组件。

看如下这个问题在各种社会形态里如何解决:一个人(对象使用者)需要一把斧子(对象)：
(1)原始社会里，几乎没有社会分工。需要斧子的人(调用者)只能自己去磨一把斧子(对象)。对应的情形为:Java程序里的使用者自己创建对象。
(2)进入工业社会，工厂出现。斧子不再由普通人完成，而在工厂里被生产出来，此时需要斧子的人(使用者)找到工厂，购买斧子，无须关心斧子的制造过程。对应Java程序的简单工厂的设计模式。
(3)进入“按需分配”社会，需要斧子的人不需要找到工厂，坐在家里发出一个简单指令:需要斧子。斧子就自然出现在他面前。对应Spring的依赖注入。

在这个问题的演化过程中需要从使用者自己创建对象、管理对象依赖的组件装配的流程到使用者完全不关心对象的创建和组件的装配过程观念转变，这个观念的就是：让别人为你服务，不再是需要什么东西自己去造出来，而是需要什么东西让别人送过来，说的就是控制反转（Inversion of Control，IOC）。对象使用者和对象彻底解耦。由此明确下控制反转的具体含义：

1. 谁控制谁：在传统的开发模式下，我们都是采用直接 new 一个对象的方式来创建对象，也就是说你依赖的对象直接由你自己控制，但是有了 IOC 容器后，则直接由 IoC 容器来控制。所以“谁控制谁”，当然是 IoC 容器控制对象。
2. 控制什么：控制对象。
3. 为何是反转：没有 IoC 的时候我们都是在自己对象中主动去创建被依赖的对象，这是正转。但是有了 IoC 后，所依赖的对象直接由 IoC 容器创建后注入到被注入的对象中，依赖的对象由原来的主动获取变成被动接受，所以是反转。
4. 哪些方面反转了：所依赖对象的获取被反转了。（摘自【死磕 Spring】—– IOC 之深入理解 Spring IoC）

设计目标和理念

Spring的设计目标是为我们提供一个一站式的轻量级应用开发平台，抽象了应用开发中遇到的共性问题，提供一个企业级开发的生态环境，这是和其他大部分专注于某个或某些问题领域的框架产品最大的区别。可以把spring和unix类的操作系统进行类比（这个观点来自《spring技术内幕》一书），操作系统作为用户和机器之间的平台，向用户程序提供简单一致的机制来控制复杂而又大相径庭的低级硬件设备，为用户使用底层的硬件机器资源提供了应用开发环境，而spring是为开发者对企业级应用资源的使用提供了技术抽象，提供了更易于使用的接口和方式。两者从设计上都可以分为三个层次：核心、组件、应用。

spring的核心模块（IOC容器和AOP模块）相当于操作系统的内核，操作系统使用进程等核心概念来抽象计算等硬件资源，为用户程序运行提供了抽象；对spring来说，它通过IOC容器来管理轻量级的POJO对象以及它们的耦合关系，使资源能够很好地用java对象来抽象、描述和管理，另一方面，可以通过AOP，以动态和非侵入式的方式来增强服务的功能，自动化的通用性处理。IOC容器和AOP模块作为spring的核心，是实现spring生态中其它模块的基础。

在核心模块的支持下，spring提供了许多开箱即用的系统组件（事务处理、mvc、security、email、batch等等），大大简化了企业级javaEE领域的问题，使得应用可以更关注业务逻辑的处理。由于spring本身的松耦合设计理念，可以让应用通过简单的开发接口或现成的应用模板就可以方便地使用这些组件和服务。

在处理与现有的优秀解决方案的关系时，它致力于为应用提供使用优秀方案的集成平台。正是这样兼容并包的平台思维和设计理念，不断地丰富着spring的生态系统。