configuration - アプリケーション構成のシングルトン

Question

これまでのすべてのプロジェクトで、シングルトン パターンを使用して、アプリケーション全体のアプリケーション構成にアクセスしていました。このパターンはテスト容易性を向上させず、コンポーネントの依存関係を隠すため、最近、シングルトン パターンを使用しないことを検討している多くの記事を目にします。私の質問は、構成オブジェクトをアプリケーション全体に渡すことなく、アプリケーション全体で簡単にアクセスできるアプリケーション構成を格納する最良の方法は何ですか?

前もって感謝します

マドゥ

Answer 1

アプリケーション構成は、Singleton パターンの優れた使い方だと思います。アクセスするたびに構成を再読み込みする必要がないように、また、構成を厳密に型指定する必要があるため (つまり、毎回非文字列値を変換する必要がないため)、自分で使用する傾向があります。私は通常、テスト容易性をサポートするためにシングルトンにいくつかのバックドア メソッドを組み込みます。つまり、XML 構成を挿入してテストで設定できるようにする機能と、必要に応じて再作成されるようにシングルトンを破棄する機能です。通常、これらはリフレクションを介してアクセスするプライベート メソッドであるため、パブリック インターフェイスからは隠されます。

編集私たちは生きて学びます。アプリケーションの構成は、Singleton を使用する数少ない場所の 1 つだと思いますが、もうこれは行いません。Lazy<T>通常、ここでは、構成プロパティの静的なバッキング フィールドを使用して、インターフェイスと標準クラスの実装を作成します。これにより、テスト容易性のためのより良い設計で、各プロパティの「一度初期化」動作を行うことができます。

Answer 2

依存性注入を使用して、単一の構成オブジェクトをそれを必要とするクラスに注入します。このようにして、モック構成をテストなどに使用できます。明示的に外に出て、構成ファイルで初期化する必要のあるものを取得する必要はありません。依存性注入では、オブジェクトを渡すこともありません。

Answer 3

その特定の状況では、1 つの構成オブジェクトを作成し、それを必要とする人に渡します。

これは構成であるため、アプリの特定の部分でのみ使用する必要があり、必ずしも遍在する必要はありません。

ただし、それらの使用に問題がなく、それほど難しいテストをしたくない場合は、今日までと同じように続行する必要があります。

それらが有害であると考えられる理由についての議論を読んでください。ほとんどの問題は、多くのリソースがシングルトンによって保持されているときに発生すると思います。

アプリの設定はそのままでいいと思います。

Answer 4

コンポーネントが実行時に変更できる構成に依存している場合 (ウィジェットのテーマ サポートなど)、変更された構成について通知するためのコールバックまたはシグナリング メカニズムを提供する必要があります。そのため、作成時に必要なパラメーター (色など) のみをコンポーネントに渡すだけでは十分ではありません。また、コンポーネント内から構成へのアクセスを提供する (完全な構成をコンポーネントに渡す) か、最終的に変更を適用できるように、構成とその作成されたすべてのコンポーネントへの参照を格納するコンポーネント ファクトリを作成する必要があります。

前者には、コンストラクターが乱雑になったり、インターフェイスが壊れたりするという大きな欠点がありますが、プロトタイピングにはおそらく最速です。「デメテルの法則」を考慮に入れると、カプセル化に違反するため、これは大したことではありません。後者には、コンポーネントが必要なものだけを取得する特定のインターフェイスをコンポーネントが保持し、おまけとしてリファクタリングの中心的な場所 (ファクトリ) を提供するという利点があります。長期的には、コードのメンテナンスはファクトリ パターンの恩恵を受ける可能性があります。

また、ファクトリがシングルトンであったとしても、構成シングルトンよりもはるかに少ない場所で使用される可能性があります。

Answer 5

シングルトンパターンが進むべき道のようです。これは私が書いたSettingクラスで、私にとってはうまくいきます。

Answer 6

Castale.Core>>DictionaryAdapterとStructureMapを使用して行われた例を次に示します。