Spring学习（一）---依赖注入（DI）1

任何一个有实际意义的应用都是由两个或者更多的类组成，这些类相互之间进行写作来完成特定的业务逻辑。通常，每个对象负责管理与自己相互写作的对象（即它所依赖的对象）的引用，这将导致高度耦合和难以测试的代码。例如，考虑下面程序所展现的Knight类。

package com.springinaction.knights;

public class DamselResuingKnight implements Knigh{
prvate RescueDamselQuset  quest;
public DamselRescuingKnight(){
quest = new RescueDamselQuest();  //与RescueFamselQuest紧耦合

}

public void embarkOnQuest() throws QuestException{

quest.embark();

}
}

此时DaselRescuingKnight在它的构造函数中自行创建了RescueDamselQuest。这使得两者紧密的耦合的在一起，极大的限制了该骑士的执行探险能力，如果是救援工作则可以立马执行，但是去做其他的事情，比如杀巨龙等，该骑士就无法操作了。同时对于上述代码进行单元测试代码使则出奇的困难，无法对其进行单元测试。

<span style="font-size:24px;"> 而通过依赖注入（DI），对象的依赖关系将由负责协调系统中各个对象的第三方组件在创建对象时设定。对象无需自行创建或管理他们的依赖关系——依赖关系将被自动的注入到需要他们的对象中去。如下面代码所示：</span> 

<span style="font-family: Arial, Helvetica, sans-serif;">package com.springinaction.knights; </span>

public class BraveKnight implements Knight{

private Quest quest;

public BraveKnight(Quest quest){

this.quest = quest;

}

public void embarkOnQuest() throws QuestException{

quest.embark();

}

}

<span style="font-size:24px;"> 不同于之前的DamselRescuingKnight，BraveKnight没有自行创建探险任务，而是在构造时把探险任务作物构造器参数传入。这是依赖注入的方式之一，即构造器注入。 </span>

<span style="font-size:24px;">   此时BraveKnight没有与任何特定的Quest实现发生耦合。对它来说，被要求挑战的任务只要是实现了Quest接口，那么具体是哪一类型的探险就无关紧要了。这就是依赖注入的最大好处——松耦合。 </span>

<span style="font-size:24px;"> 创建应用组件之间协作的行为通常称为装配。Spring有多种装配Bean的方式，采用XML配置通常是最常见的装配方式。Spring通过应用上下文（Application Context）装载Bean的定义并把他们组装起来。Spring应用上下文全权负责对象的创建和组装。Spring自带了几种应用上下文的实现，他们之间主要的区别仅仅是如何加载他们的配置。</span>