Dependence Injection （依赖注入）这一名词在几天前我还没有听说过，第一次看到她是在自己拿到《程序员》2005第一期的时候在一篇“依赖倒置、控制反转、依赖注入”的文章中看到的。今天花了点时间看了看Martin fowler的Inversion of Control Containers and the Dependency Injection pattern，收获不小，对以前学J2EE时对容器实现的疑惑也有了一点理解，如果工作时间允许的话，下一步也想花点时间研究一下几个开源容器的实现，在这方面有经验的兄弟们望不吝赐教：）

        其实无论IoC还是依赖注入，都是为了满足面向对象设计的依赖倒置原则，依赖注入所注入的对象通常是个可变因素，所以如果不采用注入的手法，那只能在调用者内部进行强行的持有对象的实例，正如在以前的一篇

State模式与Strategy模式 中所述的在State模式一样，因为环境可能是一直在变的，那么如果我们想要实现操作随环境的变化而产生不同的行为的话，在环境类中持有具体状态实例是不可行的（具体状态模式参见状态模式），因为它违反了“依赖于抽象，而不依赖与抽象的实现”的设计原则。所以采取的方式如下：

        在上面的代码中，State是一个抽象类，所有状态的实现均继承自该类，所以在可变的环境类（即上面代码中的Context类）中依赖关系是在Context类以及State类之间，在这里依赖注入体现在了构造函数中传入一个状态对象，这种依赖注入的方式称之为构造子注入（Constructor Injection）,后通过一个State属性来实现设置注入依赖（Setter Injection）。当然这两种依赖注入方式可能结合起来使用，适用的情况是实现方式复杂多变、而且会发生来回的迁移，比如状态模式。如果只是单纯为了可扩展，为了消除代码的Bad Smell情况那么个人认为用构造子依赖注入即可，比如在策略模式中的使用，见拙文策略模式以及策略模式与模板方法的结合 ，还有另外一中依赖注入方式叫接口注入（Interface Injection）但个人感觉用起来不是很直观也稍显烦琐。 

        其实我个人的理解还显得很稚嫩，欢迎大家指点：）