玩玩Spring之IOC

　　Spring的功能是很强大的，在其“绝不发明自己认为好的轮子，而只发明自己认为不好的轮子”的指导思想下，通过充分实践了“一切实事求是、‘循证架构’的工作方式”的理论，基本上把轻量级的J2EE应用框架（如ORM、MVC等）进行了整合，并构架了一些常用的功能(如DAO)，形成了一个功能强大的J2EE轻量级企业应用框架。
　　然而，或许是大家对Spring掌握得还不透彻的缘故吧，看到很多软件企业中用到的Spring功能，基本上大多数都只是用其IOC功能，有时候附带用了其中的AOP事务管理功能。
　　IOC及AOP虽然不是Spring首创，然而其在这两块都是做得很不错的，应该说整个Spring框架就是围绕着其IOC实现及AOP实现架设起来的。我想，深入挖掘IOC、AOP以及Spring中的实现，使用等，对于初学者帮助会非常大，因此，从本期开始，大峡的《玩玩Spring系列》将伴随大家一起走进IOC及AOP的世界。
　　由于本人水平有限，文中难免有很多不足甚至错误之处，还请各位朋友不吝批评指教。

 

一、IOC简介
　　IOC-全称Inversion of Control，中文解释：控制反转。另外，IOC又称DI(全称)Dependency Injection，中文解释：依赖注入。
　　呵呵，这些名词搞得有点像学古文的味道哈。很多大师还都说IOC中有一个著名的好莱坞理论：你呆着别动，到时我会找你。由于本人未到过好莱坞参加过社会实践，因此，这句话理解有点困难。
　　IOC是一种新的设计模式，即IOC模式，系统中通过引入实现了IOC模式的IOC容器，即可由IOC容器来管理对象的生命周期、依赖关系等，从而使得应用程序的配置和依赖性规范与实际的应用程序代码分开。其中一个特点就是通过文本的配件文件进行应用程序组件间相互关系的配置，而不用重新修改并编译具体的Java代码。
　　当前比较知名的IOC容器有：Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等，国内由板桥里人负责的国产开源项目Jdon框架，也是具有IOC容器功能(由于没来得及认真研读其源码，似乎jdon中IOC部份是调用Pico的IOC容器功能来实现的)。
　　在上面的几个IOC容器中，轻量级的有Pico Container、Avalon、Spring、HiveMind等，超重量级的有EJB，而半轻半重的有容器有JBoss，Jdon等。
　　
　　IOC究竟是什么？IOC是如何产生的?用在什么场合?为什么我们以前不用IOC，而现在要用IOC？“物有本末，事有终始”，为了更加透彻的理解这一问题，大峡打算从自己所理解的面向对象(OO)设计及编程发展历程来进行分析，也许这样能让IOC的初学者更加了解IOC的发展的前因后果，争取做到“知其然，知其所以然，使其然!”。
　　若大家等不急了，就直接百度一下有关IOC的其它文章，这方面国内很多先驱们已经作了很多介绍。如冰云的《IOC详解》、板桥里人的设计模式及IOC理论等。

 

二、 最老的OO编程

　　记得曾经看《Think in Java》最早版本的时候，里面有这么一句让人振奋话：一切都是对象。这时我们OO编程的核心是围绕着面向对象编程的三个特性即“继承”、“封装”、“多态”来展开的。
2.1 封装
　　那时我们学会了对现实就的事物及软件模型进行了抽象。比如要描述一只猫，那么这支猫应该有“颜色”、“重量”、“公母”、“脾气”、“出生日期”等属性，另外还有“跑”、“吃”、“叫”、“猫捉老鼠”等方法。如Java代码来表示，大致就是如下：
public Class Cat
{
private String color;//颜色
private String weight;//重量
private String sex;//公母
private String temper;//脾气
private String birthday;//出生日期
private void run ();//跑
private void eat (Food food); //吃(食物)
private void shout(int type);//叫(类别)
private boolean chase(Mice mice);//猫捉老鼠
}

 

2.2 继承
　　最早的OO编程时期，我们还会引入继承，还经常鼓励大家多用继续，认为继承就是OO编程思想的核心。继承的核心就是围绕着如何把类与类之间具有共同特性的部份抽象到基类中。认为这样不但能使用了OO的特性，还减少了很多子类的代码。
　　我们通过日常生活的常识知道，猫是一种动物，因此动物有的特性他基本上都有。于是，如果我们的系统中不但有猫，还会有很多其它的动物出现。我们就会设计一个动物类，把所有动物的共性抽象到一个基类中。这里，猫及动物基类的代码大致如下：

public abstract Class Animal{
private String color;//颜色
private String weight;//重量
private String sex;//公母
private String temper;//脾气
private String birthday;//出生日期
private void run ();//跑
private void eat (Food food); //吃(食物)
private void shout(int type);//叫(类别)
}

public Class Cat extends Animal
 private int power;//能力
 private int agility;//敏捷度
   //  猫捉老鼠是特有的方法
 private boolean chase(Mice mice) {
  return true;
 };
}

 

 

2.3 多态
　　这时我们还会不时使用到OO的另外一个特性多态。多态是很重要的一门技术，然而很多时候却没有很好的理解并使用，回头看以前的代码，我们看到有很多地方属于故弄玄虚的嫌疑。
　　接上面的例子，假如我们要写一个喂养宠物(有猫、狗、猪、豹、老鼠等)的程序。利用Java的多态特性，我们的大致代码如下：
public class PetManage {
 //喂食我的宠物
 public void feeding(Animal a)
 {  
 } 
 /**
  * @param args
  */
 public static void main(String[] args) { 
  Animal myPet=new Cat();
  PetManage pm=new PetManage();    

2.4 对象生命周期

　　这一阶段的OO程序中，我们知道要用一个对象的时候，就要使用Java中的关键字new来生成一个来用即可。OO对于我们来说，一切都是那么简单，很多时候甚至感觉OO跟OP的编程方法也没太大区别。代码如下：
Cat myCat=new Cat();//创建一支具体的猫
myCat.shout();//叫一声

　　此时，我们对Java虚拟是非常信任的，我们的思想也很单纯，我们知道Java对象的生命开始于new关键词。我们不太关心对象生命的结束，我们知道Java有一个比C语言历害、智能化的垃圾收集器，他会帮我们自己的清理内存中不用的对象。
　　当然，也有的人由于对垃圾收集器忠诚度的怀疑，不放心垃圾收集器的能力，于是在程序中经常要加一句类似“myPet=null”的代码来结束对象的生命。
　　当然，我们也知道有一些外部资源如数据库连接等，需要手动熟悉资源。于是知道在使用类似资源的时候必须都加上一句：conn.close()，有时候还要在close()后面再加一句：conn=null。呵呵，非常有意思。

 

2.5小结
　　现在看来，其实那时确实犯了很多幼稚的错误，也走了不少的弯路，做了很多画蛇添足的工作，写了很多难与维护的代码。
　　对比今天的IOC模式，若要从早的OO方法中硬要找一个类似Spring的容器的话，那就是：“程序员＋JVM本身”。是程序员以及JVM一起我们管理对象的生命周期、对象之间的关系等。那时候若有任何变动都需要改代码，（虽然好的设计代码修改会非常少，但也得改！），然后编译，然后拿到测试环境及用户环境中执行。如此反复，年日复一日、年复一年。
　　那时我们的代码复用用得最多的就是OO的继承功能，另外还有很多OP方法中带过来的函数。