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