（思考）Spring第一篇之IoC

（觉得自己一直思考太少且深度不够，所以加上这个前缀提醒自己-思维才是核心竞争力。）
Spring目前可能用到的有几个模块：IoC、AOP和TX，第一篇主要对IoC一些essential的知识做一个总结，不牵扯任何技术细节上的东东，很多都是个人的一些想法，所以不一定准确，欢迎大家指出来，可以一起讨论。附件是我在写文章时候，参考的一篇文献。
一、IoC（Inversion of Control）
1.什么是IoC？
以往不好的编程体验，过于依赖于implementation，这样的结果是：implementation对整个程序拥有了绝对的control。因为implementation都是硬编码，所以造成的结果是难于扩展，无法满足OCP。IoC就是Inverse the Control of implementations to the interfaces,即面向接口编程。这样无论是上层的business，还是下层的implementation都依赖抽象层（接口或者抽象类），抽象层拥有绝对的control。这样的结果是使整个项目有了更好的extensible。
Spring框架的核心是IoC容器，所以它有着很好的No Intrusive。
介绍到这，就很想知道IoC在Spring中是如何实现的很自然的引出了第二个话题。
2.如何实现IoC？
实现IoC有两种主要的方式，一种是Service Locator（服务定位器），一种是Dependecy injection（依赖注入）。为何要引入这两种方式，举一个简单的例子可以说明这个问题。

class People{
    private Action action;
    public People(){
        action =new ManAction();
    }
}
interface Action{}
class ManAction implement Action{}

注意，上例中你虽是面向接口编程，但实际上People类，既依赖于Action接口，又依赖于ManAction（具体的implementation），而且你在编译期就binding了这种关系。这显然不是我们所期望的那种“纯粹的”面向接口编程。如何达到这个要求，有人提出了“plugin”这个概念，既我们编写的plugin是在运行时才binding到这个系统中的，插入的时间和方式，完全于plugin的编写者无关，如何做到呢？于是就有了最开始所说的的两种实现方式（模式）。
首先说说DI，DI分为三种：Type1，Type2和Type3。
Type1：interface injection，要实现它，需要再定义一个接口叫ActionInjection每个使用Action的类都必须实现这个接口，然后在配置文件中定义injection属性，把ManAction作为value传入进去即可。这种方式由于要在你自己的类（比如People）中实现ActionInjection接口，于框架的耦合度较高，所以具有较强的Intrusive，不推荐使用。而Type2和Type3，即是Spring所使用的方式。网上有很多关于它们的讨论，我大致总结一下：Type3使用构造子注入，优先使用，因为它具有较强的隐蔽性，可以保护你不愿意改变的属性；然而有时候，会有多个构造函数，或者是构造函数的参数很多（记住顺序很麻烦），就应该使用Type2Setter方法注入。
最后说说Service Locator（SL），我对它的理解应该也不准确，大概说说也算是抛砖引玉吧。DI中控制者和被控制者，完全感受不到对方的存在，它们之间的关系是在runtime时才binding的，具有很强的灵活性，然而正是因为这种灵活性若是超过了一定限度，会使你迷失在查找配置文件的海洋中。而SL要求必须在编译器就有一个SL对象知道你Application所需的全部服务，而具体这些服务的注册是通过DI在runtime时和Application所需要的SL对象binding在一起的，所以SL一般会是一个接口，而你的Application在runtime中通过SL对象查找服务，然后调用它，这样的好处是，你可以显示的看到你所拥有的全部的服务，和配置文件解耦。
到这里，可以把IoC想象为一个实体东西，它的“体”是control，“相”是inverse，“用”呢？
3.用IoC干什么？
换个角度说，就是用IoC操作什么？答案是Beans。操作的过程与Spring框架紧密结合在一起，Spring框架提供了两个方式一个是BeanFactory接口，一个是使用Application Context容器，下面这段话解释的很清楚，不再赘述。

引用

Aside from the additional functionality offered by application contexts,another big difference between an application context and a bean factory is how singleton beans are loaded. A bean factory lazily loads all beans, deferring bean creation until the getBean() method is called. An application context is a bit smarter and preloads all singleton beans upon context startup. By preloading singleton beans, you ensure that they will be ready to use when needed—your application won’t have to wait for them to be created.

我们按照DI配置好了Beans，那么就需要使用它们，而在使用的时候，我们还可以控制它们的生命周期，几个比较重要的生命周期有：
singleton：顾名思义，这整个IoC容器中只有一个实例。要想具有与单例模式中单例共同的作用，我觉得需要在第一次初始化容器的时候，读入全部的配置文件（不知道对不对），即让容器具有与JVM同样的作用域。
prototype：有点像new操作符，该bean每次被注入后都会重新创建一个实例，主要用于stateful bean。在这里我有一个想法，比如典型的购物车，应该是一个stateful bean如果在每个客户session内，把记录暂时存放在客户的硬盘上可以在需要使用时候从硬盘读出，这样不是就可以把stateful bean改写为stateless bean吗？
知道了操作的是Beans，下来就要关心是怎么操作的。
4.如何管理Beans？
对于由容器托管的Beans，你可以自己写init方法和destroy方法。可以通过implement interface，configure document和annotations三种方式来实现。Spring提供了更加高级的管理方式，不过这些一般也用不到，属于no essential的知识，什么时候用什么时候再细看吧，大体就是提供几个接口，继承这些接口，你就会获得一些特性，插入到Spring容器的管理lifecycle中，发布自己的需要的特性。