3

真正 SOLID 代码的一个重要特性是构造函数调用并不经常发生在实际应用程序代码中，而是主要在必要的组合根和工厂方法中发生。这对我来说很有意义，我会尽可能地坚持这一点。

我创建了一个简单的类，在我看来，它不仅是允许的，而且实际上是正确的，可以偏离上述规则。这抽象了一些简单的 Registry 查询，以方便对其他一些代码进行单元测试：

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()方法实际上在不使用工厂的情况下创建了同一个类的实例，但是由于 Registry 呈现的封闭概念，我实际上似乎不希望返回任何看起来像 Registry 键的东西，但实际上确实可以正常工作的东西与当前对象相同。

我知道最终取决于我想要工作的 SOLID 程度，但我想知道由于基本概念的性质，这通常是否是可行的路径，或者这是否不是例外遵守规则，但实际上违反了 SOLID。

4

1 回答 1

1

你说的是依赖倒置原则。这个原则并不是说你根本不应该新建对象，但它区分了两种类型的对象。实现行为的对象（服务），以及包含数据的对象（DTO、值类型、实体）。

不更新 DTO 是相当愚蠢的，因为没有要抽象的行为。它们只包含数据。（就像将IPerson接口添加到PersonDTO 一样愚蠢）。

Miško Hevery 称它们为injectables和newables，这是一个很好的术语。

有关更多信息，请参阅这个 Stackoverflow 问题：为什么不使用 IoC 容器来解决实体/业务对象的依赖关系？

于 2012-06-14T09:58:26.780 回答