3

実際の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違反です。

4

1 に答える 1

1

あなたは依存性逆転の原則について話している。この原則は、オブジェクトをまったく更新してはならないということではありませんが、2つのタイプのオブジェクトを区別します。動作を実装するオブジェクト（サービス）、およびデータを含むオブジェクト（DTO、値型、エンティティ）。

抽象化する動作がないため、DTOを更新しないのはかなりばかげています。データが含まれているだけです。（ DTOにIPersonインターフェイスを追加するのはばかげているのと同じように）。Person

MiškoHeveryはそれらを注射剤とnewablesと呼んでいます。これは素晴らしいterminolgoyです。

詳細については、このStackoverflowの質問を参照してください：エンティティ/ビジネスオブジェクトの依存関係を解決するためにIoCコンテナを使用しないのはなぜですか？

于 2012-06-14T09:58:26.780 に答える