2012-06-13 35 views
3

真正SOLID代码的一个重要属性是构造函数调用不经常发生在实际的应用程序代码中,但主要是在必要的组合根和工厂方法中发生。 这对我很有意义,我坚持这一点,只要我可以。SOLID:允许同类构造函数调用吗?

我创建了一个简单的类,在我看来,它不仅被允许,而且实际上正确地偏离了上述规则。 这种抽象一些简单的注册表查询方便一些其他的代码进行单元测试:

public class RegistryKeyProxy : IRegistryKey 
{ 
    private RegistryKey registrykey; 

    public RegistryKeyProxy(RegistryKey registrykey) 
    { 
     this.registrykey = registrykey; 
    } 

    public IRegistryKey OpenSubKey(string subKeyName) 
    { 
     var subkey = this.registrykey.OpenSubKey(subKeyName); 

     return (null == subkey ? null : new RegistryKeyProxy(subkey)); 
    } 

    public IEnumerable<string> GetSubKeyNames() 
    { 
     return this.registrykey.GetSubKeyNames(); 
    } 

    public object GetValue(string valueName) 
    { 
     return this.registrykey.GetValue(valueName); 
    } 
} 

OpenSubKey()方法实际上不使用工厂创建此相同的类的实例,但由于封闭的概念,注册表礼物,实际上,我似乎不希望返回看起来像注册表项的任何东西,但确实与当前对象的工作方式完全相同。

我知道最终取决于我想要如何工作,但我想知道这是否是一条可行的途径,因为基本概念的本质,或者如果这并不是该规则的例外,但实际上是一个实体违规。

+2

“一个真正坚实的代码的最重要的特性是,构造函数(除不能无论如何更换,无需破译密码的基本框架类函数)永远不会在实际应用程序代码中调用“ - 需要引用。 –

+2

调用它自己的构造函数的类是一个私有实现细节,对于类中的代码紧密耦合在其私有实现细节中是完全合理的。这里没有介绍新的依赖关系。 –

+0

@DonRoby:我承认措辞有点过于绝对,但是从我的理解来看,这是SOLID工作的主要内容之一。我还记得有一天我读了一些与Mark Seemann非常接近的东西(尽管我不记得在哪里)。 – TeaDrivenDev

回答

1

您正在谈论Dependency Inversion principle。这个原则并不是说你根本不应该创建对象,而是区分两种类型的对象。实现行为的对象(服务)以及包含数据的对象(DTO,值类型,实体)。

由于没有任何行为需要抽象,所以在DTO中不会创新就显得很愚蠢。他们只是包含数据。 (就像将一个IPerson接口添加到Person DTO中一样愚蠢)。

MiškoHevery称他们为injectables and newables,这是一个不错的terminolgoy。

欲了解更多信息,请参阅本#1问题:Why not use an IoC container to resolve dependencies for entities/business objects?

+0

感谢您的简要说明;这很有道理。注射剂和新药确实是一种可以考虑的方法。 – TeaDrivenDev

相关问题