真正的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()
方法实际上创建了同一个类的实例而没有使用工厂,但由于注册表提供了封闭的概念,我实际上似乎不希望返回任何东西它看起来像一个注册表项,但实际上与当前对象完全相同。
我知道最终由我来决定我想要的工作方式,但我想知道这是否是一条可行的途径,因为潜在概念的性质,或者如果这是不是规则的例外,但实际上是SOLID违规。
答案 0 :(得分:1)
您在谈论Dependency Inversion principle。这个原则并没有说你根本不应该新建对象,但它区分了两种类型的对象。实现行为(服务)的对象,以及包含数据的对象(DTO,值类型,实体)。
如果没有新的DTO,那将是相当愚蠢的,因为没有任何行为被抽象化。它们只包含数据。 (就像向IPerson
DTO添加Person
接口一样愚蠢。
MiškoHevery称他们为injectables and newables,这是一个很好的终极术。
有关详细信息,请参阅此Stackoverflow问题:Why not use an IoC container to resolve dependencies for entities/business objects?