Dependence Injection

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

        其实无论IoC还是依赖注入，都是为了满足面向对象设计的依赖倒置原则，依赖注入所注入的对象通常是个可变因素，所以如果不采用注入的手法，那只能在调用者内部进行强行的持有对象的实例，正如在以前的一篇状态模式），因为它违反了“依赖于抽象，而不依赖与抽象的实现”的设计原则。所以采取的方式如下：
    

    /// 状态模式的环境类，用与控制状态间的转换
    /// </summary>
    public class Context
{
        private State state;


        /// 环境的初始化
        /// </summary>
        /// <param name="initState">初始化状态</param>
        public Context(State initState)
{
            this.state=initState;
        }


        /// 环境类所维护的状态属性
        /// </summary>
        public State State
{
            get
{
                return this.state;
            }
            set
{
                this.state=value;
            }
        }


        /// 环境接口
        /// </summary>
        public void ContextIterface()
{
            Console.WriteLine("State Context Interface called");
            this.state.MainCalculateLogic();
        }
    }

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

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