春天不寒----谈spring的依赖注入

 

当我第一次看到spring的时候就觉得似曾相识。这分明就是反射+配置文件+工厂模式。这样的框架是按照一些准则把设计模式打包成高层的模式。而spring技术中最闪耀的名词绝对少不了控制反转(IoC)，依赖注入(D Injection)和依赖倒置(D Inversion)。

不管这些是方法论，还是模式，还是原则，有了这三样东西程序员的春天确实来了。不必再为了每一次的变化而心寒和纠结了。那么这又“反转”又“注入”又“依赖”的，到底是些什么东西呢？他们在干什么呢？不用行么？那么麻烦值得么？再有spring真的这么特别么，别的世界就没有spring么？

首先澄清下概念：“控制反转”，比方说本来你对某样事物有主动控制权，但是你却交了出去，那么你从主动控制转为被动，此即控制反转；“依赖注入”，一个实体依赖另一个实体，但在早期不体现这种依赖关系，而是把这种依赖关系提取出来，在后期注入回去；“依赖倒置”，以前高层依赖底层，但是底层变化后高层就没用了，后来不让高层依赖底层，让它依赖接口，这就是依赖的倒置，面向接口编程就是依赖倒置的灵魂。

以上是我用自己的话对几个概念的解释。不懂没关系，往下看。

    先讲个实际生活的例子，假如某一天，您和您一哥们出去吃饭。坐到餐馆以后，您哥们说，“吃什么啊？”；你懒洋洋的说“随便”。

好，故事先就此打住。您这一随便不要紧啊，把吃什么的控制权交了出去啊，于是您和具体食物的关系算是没有了，因为您哥们说得算了。这就是控制反转，本来您可以决定吃米饭还是馒头，但是现在你只知道等下有东西吃但是吃什么你不知道了，因为控制具体吃什么的是您哥们。不过有一条，他一定会给你点能吃的，不能搞来一把锤子，虽然你把控制权交了出去，但是你还是有最基本的要求，能吃，此为一个接口。而后来不管上什么都要实现这个能吃的接口，此为依赖倒置或者说面向接口编程。

接下来，您哥们仔细想了半天，在点菜单上画了这个涂了那个，可他就是不说点了什么，最后给服务员去做了。等了若干分钟，上来两碗米饭，一个小鸡炖蘑菇，一个酸辣土豆丝。

到了此时您才看到他点了什么菜叫了什么饭，这就是依赖注入了。本来您和米饭和小鸡炖蘑菇是有依赖关系的，因为你要吃它们，但是在开始的时候却把你们隔离开，到了吃的时候你才看到它们。

下面我把伪类图画出来

 

简单的写下代码：

 

//约定的接口，和实现此接口的两个类。

interface Eatable{

    public void eat();

}

 class Rice implements Eatable{

     public void eat(){

        // 天天吃米饭，真幸福啊！！

     }

 }

 class Chicken implements Eatable{

     public void eat(){

        // 如果天天吃鸡，那就是黄鼠狼啊！！

     }

 }

 // 上层使用者，只需要知道接口，根据配置文件在运行时加载需要的类

 class You{

     private Eatable meal;

     public void eatmeal{

        Resource rs =new ClassPathResource("beans-config.xml");// 加载配置文件

        BeanFactory factory = new XmlBeanFactory(rs);         

        this.meal = (Eatable)factory.getBean("eat");

        this.meal.eat();         //可算开始吃饭了，但直到饭菜上桌才知道吃什么，哎，悲惨

     }

 }

 

下面是beans-config.xml的主要内容

 

<bean id="eat" 

    class="Chicken" > //这里就可以灵活改变了。

</bean>

    上面的代码基本演示了这个小故事和依赖注入等相关概念，但这并不是spring的标准开发，虽然这么做无可厚非，利用接口提供服务，并动态调用，这也是依赖注入的一种方式。However，spring只支持设值注入和构造注入，设值注入比较常用，如下更改就是spring的标准设值注入。

   

 class You{

     private Eatable meal;

     public void setMeal(Eatable meal) {//一定要有setter

        this.meal = meal;

}

     public void eatmeal{

        //Resource rs =new ClassPathResource("beans-config.xml");// 加载配置文件

        //BeanFactory factory = new XmlBeanFactory(rs);         

       //this.meal = (Eatable)factory.getBean("eat");

        this.meal.eat();         //可算开始吃饭了，但直到饭菜上桌才知道吃什么，哎，悲惨

     }

 }

而新的配置文件如下：

 

<bean id="you" class="You" >

<property name = “meal”>

<REF local = “eat”>   

</property>

</bean>

<bean id =”eat” class = “Rice”/>

这样改变以后，实现Eatable接口的类就会被spring的IoC容器动态注入到类You中，而类You也可以被包装成实现了某个接口的javabean，在更上层应用中使用那个接口来进行操作，而加载过程如出一辙。

在spring世界里，整个流程被框架化了，用配置文件把使用者和javabean或者bean与bean之间解耦。不管什么技术什么模式，要想解耦，一定会抽象出更多的中间层以增加间接性，直接的叫高内聚但是不灵活。为了灵活自己没事找事增加间接性。这就是spring干的事情。也是很多设计模式干的事。

那么回过头再说说，spring所体现出来的解耦，依赖注入是它的专利么？

这问题回答起来太干脆了：不是。在.NET世界，我们习惯使用反射来动态加载类，而在load时使用读配置文件的办法。这样高层的代码编译发布以后不用再变化，只需要改需要加载的装配件和配置文件就好了。

 

依赖注入就是把原先在一起但没必要在一起的两样东西分开，但是他们毕竟还是有关系的，所以我们就用胶水把他们再粘到一起。整个就是没事找事。

 

                                                    by 千冰念 @ YITIAN Studio