大規模で複雑なソフトウェア製品では、構成可能な設定を管理することは大きな苦痛になります。私が見た問題に対する2つのアプローチは次のとおりです。
これらのアプローチはどちらも私には間違っていると感じています。
問題を単純化するために使用できる設計パターンはありますか? 依存性注入技術を利用するものかもしれません。
クエリの設定、読み込み、および保存のためのインターフェイスを作成することを好みます。依存性注入を使用することで、それを必要とする各コンポーネントにこれを注入できます。
これにより、構成戦略を置き換えるという点で柔軟性が得られ、すべてが機能するための共通の基盤が提供されます。特に、絶対に必要な場合は、単一のコンポーネントの構成メカニズムをオーバーライドできるため、単一のグローバルな「設定ローダー」(オプション 2) よりもこれを好みます。
現在、構成キーから値へのマップを保持する 1 つのグローバル シングルトン オブジェクトによって構成が管理されるシステムで作業しています。一般に、システムで同時実行性のボトルネックが発生する可能性があり、単体テストなどでだらしないため、この方法が行われていなかったらよかったのにと思います。
Reed Copsey にはその権利があると思います (私は彼に投票しました) が、依存性注入に関する Martin Fowler のすばらしい記事を読むことを強くお勧めします。
http://martinfowler.com/articles/injection.html
ちょっとした補遺もあります...モックオブジェクトタイプの単体テストを行いたい場合は、依存性注入が間違いなく適しています。
これはどう。1 つのメソッド configure(configuration) でインターフェイス Configurable を定義します。構成引数は、構成パラメーターの名前とその値を関連付ける単純なハッシュテーブルです。
ルート オブジェクトは、任意の方法で構成ハッシュ テーブルを作成できます (例: 構成ファイルから読み取る)。このハッシュテーブルには、ルート オブジェクト iselft の構成パラメーターと、そのコンポーネント、サブコンポーネント、サブサブコンポーネント (など) のいずれかが使用するパラメーターが含まれる場合があります。
次に、ルート オブジェクトは、構成可能なすべてのコンポーネントで configure(configuration) を呼び出します。