web-dev-qa-db-ja.com

構成クラス/構造：パターンまたはアンチパターン？代替案？

プログラムに新しい構成オプションを追加すると、多くの場合、オプションを実行する必要がある場所にオプションを取得するという点で、大量の波及効果が生じる可能性があります。私が知っているこれに対処する3つの基本的な方法があります。

  1. すべての構成設定を、プリミティブとして明示的に必要とするプログラムの部分に渡します。これは最も明示的な方法であり、物事を最も分離する方法です。欠点は、これが冗長であり、もろいことです。

  2. 最も頻繁に使用される構成設定をグローバル/静的にします。これは最も簡単な方法ですが、距離を置いてアクションを導入し、テスト性を妨げ、構成が本当にグローバルであると想定します（常に1つの構成しか必要ない）。

  3. プログラム全体またはプログラム内の主要な懸念事項のすべての構成オプションを含む構成クラス/構造体を作成し、これを明示的に渡します。これは、（1）より明確ではありませんが、（2）より明確です。 1つの関数呼び出しのみの設定を変更する場合は、構成オブジェクトを複製して、この1つの値を変更できます。これは、テストと実際の両方で役立ちます。ただし、必要のない関数に大量の情報を渡してしまう可能性があり、configクラス/構造体の値を変更しても、離れた場所でアクションが発生する可能性があります。

（3）パターンとアンチパターンのどちらを検討しますか？アンチパターンの場合、代わりに何をしますか？

designtestingconfigurationobject
10
dsimcha

bestソリューションは、いくつかの構成インターフェイスを作成し、必要に応じてそれらを実装することです。これにより、アクセシビリティが制限され、ローカライズが維持されます。ただし、すべての構成を1つのクラスにまとめて、さらに多くの問題がある問題に取り掛かるだけの価値はありません。これは構成であり、UtterlyCrucialAlwaysChangingClassではありません。ほとんど同じままです。すべてをグローバルにせず、実装に一貫性がある限り、心配する必要はありません。

4
DeadMG

デカップリングによりテストが容易になり、オブジェクトが依存する構成設定が明示的にされるため、オプション1を選択します。オブジェクトが構成設定を必要とする場合は、コンストラクター引数またはセッターメソッドによってオブジェクトに明示的に提供します。依存関係注入フレームワークを使用してこれらの構成設定をオブジェクトに注入することにより、冗長性を減らします。

1
Jim Huang

「3層（インターフェイス、ビジネスロジック、データアクセス）」アプローチを使用しているプロジェクトに取り組んでいます。アプリケーションは、マルチユーザーWebサーバーまたはクライアントサーバーにすることができます。

私たちは、ユーザーが作業しているかどうか、PCに固有の3つの異なる構成で作業します。 2番目は現在のユーザーに固有、3番目はすべてのユーザーとクライアントアプリのグローバル構成です。

各構成は、アプリケーションの各インスタンスでオブジェクトによって表されます。

このアプローチは、プロジェクトに役立つ場合があります。

0
umlcat

構成ファイルがXMLで記述されていると想像してください。次に、このXMLのフラグメントを各コンポーネントに渡すだけで、構成データを取得できます。

.NETを使用している場合は、DataContractsを使用してクラスを作成し、XmlSerialiserを使用して構成Xmlからオブジェクト階層を作成し、これらのオブジェクトを構成として渡すことができます。

これにより、次の問題が発生します。構成データには3つの異なる部分があります。この特定の製品として動作するようにコードライブラリを編成する構造的なアプリケーション構成。インストール固有の設定とシステムの各ユーザーによって異なるユーザー設定/設定データを含むサイト構成設定。

どの部分がどの部分であるかを把握し、これらのデータ設定を別々にしておくと、更新を簡単にインストールできます（顧客の設定を失うことはありません）。

0
Michael Shaw

オプション＃3のクラスを静的にします。だから代わりに

//create SomeCl
Foo f = new Foo();
f.setConfigInst(cfg);
...
...
//Inside Foo
public void setConfig(MyAppConfig c) { localCfg = c; }
...
//somewhere else:
x = localCfg.getConfigForX();

あなたはただ持つことができます：

//Inside Foo
x = MyAppConfig.getConfigForX();

構成データのロード/保存の詳細をMyAppConfigクラス内で発生させます。もちろん、目的に応じてクラスを変えるなど、より複雑なバリエーションを作成することもできます。

このアプローチが問題となる唯一のケースは、何らかの理由で異なる構成の複数のインスタンスで作業する必要がある場合です同時にこのような状況にまだ遭遇していません。

0
FrustratedWithFormsDesigner