设计模式 – 控制反转和依赖注入

如果classA依赖于classB,如果它在其中声明了classB的实例.它依赖于classB,由于某种原因(我稍后会谈到),不好,因此我们使用DI来解决这个问题.所以现在我们有一个名为IClassB的接口,它将在classA的构造函数中传递(我在这里采用构造函数注入,为了说明).这里是代码：

public class ClassA
{
    IClassB _classBObj = null;

    public ClassA(IClassB classBObj)
    {
         _classBObj = classBObj;
    }

    public void UseClassBMethod()
    {
        this._classBObj.classBMethod();
    }
}

public class ClassB:IClassB
{

    public void classBMethod()
    {
        //Some task carried out by classB.
    }
}

public interface IClassB
{
    void classBMethod();
}

这里有代码使它运行：

class Program
{
    static void Main(string[] args)
    {
        //This code is outside of class A and hence declaring 
        //object of ClassB is not dependency
        ClassA classA=new ClassA(new ClassB);
        classA.UseClassBMethod();

    }
}

我已经演示了上面的例子,以确保我对IoC和DI的理解是否正确.如果您发现任何错误,请纠正我.
现在,当我试图找出IoC的原因时,我发现了两个重要原因：

>可测试性：当然是正确的问题.让我们假设,在上面的例子中,例如,classB方法使用SMPTP服务器或某些WCF / Webservice,我们可能无法测试它.但是,我们可以创建一个实现接口IClassB的测试存根类,并通过传递测试存根类的实例继续进行测试.
>在具体实施方面的依赖性：这是我无法与之相处的.即使我使用以下代码更改classA的代码：

public class ClassA
{
   ClassB _classBObj = null;

   public ClassA()
   {
     _classBObj = new ClassB();
   }

   public void UseClassBMethod()
   {
      this._classBObj.classBMethod();
   }
}

IoC如何帮助摆脱由于ClassB对象的classB方法的变化而引起的任何问题？如果方法签名有任何变化,我们也必须在接口IClassB的方法签名中进行更改(事实上,这正在增加重构任务.).如果方法实现更改说例如它需要额外的日志记录任务,则更改将仅限于ClassB代码.

我可能对这个问题看起来有点愚蠢,但是有人会提出这样一种场景(除了单元可测性之外)我们从这种方法中受益了吗？

非常感谢您阅读本文.