这是将类注入另一个现有类的标准方法答案

【问题标题】：Which is a standard way to inject a class to another existing one这是将类注入另一个现有类的标准方法
【发布时间】：2016-07-20 23:16:10
【问题描述】：

我有这样的课：

public class myoldClass:ImyoldClass
{
  private string _a; 
  private string _b; 

  public myoldClass (string a, string b)
  {  
      _a = a; 
      _b = b;
   }

}

现在这个类被用于 20 个不同的类。我想在 myoldClass 的方法之一中使用 Memcache 类（继承自 IMemcache），但是如果我在该方法中实例化该类，它一点也不好，因为该类取决于网络连接和缓存服务器的可用性。因此，我无法为解决方案保留标准 TDD。标准方法是我必须实例化一个新的 Memcache 类，然后将其作为参数传递给构造函数。但我必须更改其他 20 个使用 myoldClass 的类。但是另一种方式可以是这样的：

public class myoldClass:ImyoldClass
{
  private string _a; 
  private string _b; 
  private IMemcache _memcache; 

public myoldClass(string a, string b, IMemcache memcache)                  
{
    _a = a; 
    _b = b; 
    _memcache = memcache; 
}
  public myoldClass (string a, string b)
  {  
      _a = a; 
      _b = b;
      _mencache = new Memcache(); 
   }

}

以这种方式，那些使用此类的类将继续从旧构造函数中使用它，我直接为它们实例化 Memcache，在单元测试中，我使用另一个新构造函数并接受 IMemcache 作为其参数之一.

我的问题：添加第二个构造函数是解决问题的标准方法吗？改变所有需要的地方不是比添加这个构造函数更好吗？

【问题讨论】：

解决问题的标准方法是使用依赖注入框架来获取myoldClass 的实例，而不是使用new myoldClass。
你的意思是从依赖注入中获取 Memcache() 的实例吗？因为这里的问题是 Memcache 而不是 myoldClass。
就像@ScottChamberlain 所说，标准的方式是使用依赖注入框架来构造myoldClass 的对象。一旦你建立了你的 DI 框架，它就会创建你所有的 myoldClass 实例，这将阻止你每次更改代码时都必须检查代码并更改数十行代码构造函数。有问题的设计的标志是当您有一个依赖项（在您的情况下为Memcache）时，您在其他类中是new-ing。最好让所有构造函数都采用 IMemcache 参数。
感谢所有回答。

标签： c# class unit-testing constructor

【解决方案1】：

如果myoldClass 是现有类，并且您想注入IMemcache 参数同时保持与非DI 构造的类的向后兼容性，您可以这样做：

public myoldClass(string a, string b, IMemcache memcache = null)                  
{
    _a = a; 
    _b = b; 
    _memcache = memCache ?? new Memcache(); 
}

DI 容器将提供参数，但您现有的构造函数调用仍然有效。

【讨论】：