プロパティへの正しいアプローチ

StackOverflow https://stackoverflow.com/questions/250560

質問

私はJavaでかなり大きなプロジェクトに取り組んでいます。私の質問は、アプリケーションの一連のプロパティを最適に構成する方法についてです。

アプローチ1：すべてのクラスからアクセス可能な静的なPropertiesオブジェクトを用意します。 （欠点：その後、一部のクラスは、アプリケーションのコンテキストから取り出されると一般性を失います。また、別のクラスにあり、将来消える可能性がある静的オブジェクトへの明示的な呼び出しが必要です; 感じる正しい、私は間違っていますか？）

アプローチ2：プロパティをメインクラスでインスタンス化し、他のアプリケーションクラスに引き継ぐ。 （欠点：プロパティオブジェクトへのポインターをほぼすべてのクラスに渡すことになり、非常に冗長で扱いにくくなるようです。私はそれを好きではありません。）

提案はありますか

役に立ちましたか？

解決

多くのプロパティにSpring依存性注入を使用するのが好きです。アプリケーションをビルディングブロックのように扱い、それらを必要とするコンポーネントにプロパティを直接注入できます。これにより、カプセル化が保持されます（奨励されます）。次に、コンポーネントを組み立てて、「メインクラス」を作成します。

依存性注入の素晴らしい副作用は、コードをより簡単にテストできることです。

他のヒント

実際、アプローチ2は非常にうまく機能します。

最近のプロジェクトでシングルトンプロパティオブジェクトを使用してみました。次に、機能を追加するときが来たら、シングルトンを修正する必要があり、 MySingleton.getInstance（）を使用したすべての場所を特定する必要があることを後悔しました。

さまざまなコンストラクターを介してグローバル情報オブジェクトを渡すアプローチ2は、制御が容易です。

明示的なセッターの使用も役立ちます。

class MyConfig extends Properties {...}

class SomeClass {
    MyConfig theConfig;
    public void setConfi( MyConfig c ) {
        theConfig= c;
    }
    ...
}

これはうまく機能し、どのクラスが実際に構成情報を必要とするかを正確に厳密に制御できて満足です。

多くのクラスでプロパティが必要な場合は、アプローチ1に進みます。または、すべての静的メソッドの代わりにシングルトンデザインパターンを使用するバリアント。これは、いくつかのプロパティオブジェクトを渡し続ける必要がないことを意味します。一方、これらのプロパティが必要なクラスが少数の場合は、前述の理由からアプローチ2を選択できます。また、作成したクラスが実際に再利用される可能性はどれくらいか、もしそうなら、プロパティオブジェクトも再利用するのはどれくらいの問題かを自問することもできます。再利用する可能性が低い場合は、気にせずに、現在の状況で最も簡単なソリューションを選択してください。

構成マネージャーコンポーネントが必要なようです。これは、 ConfigurationManagerClass.instance（）のような単純なサービスロケーターを介して検出されます。これはすべての楽しみをカプセル化します。または、Springのような依存性注入フレームワークを使用できます。

多くは、コンポーネントがアーキテクチャ内でお互いを見つける方法に依存します。他のコンポーネントが参照として渡されている場合、それを行います。ただ一貫してください。

何かをすばやく探している場合は、システムプロパティを使用できます。すべてのクラスで使用できます。文字列値を保存するか、「もの」のリストを保存する必要がある場合は、System.Properties（）メソッドを使用できます。これは、HashTableである「プロパティ」オブジェクトを返します。その後、必要なものをテーブルに保存できます。それはきれいではありませんが、グローバルなプロパティを持っている簡単な方法です。 YMMV

私は通常、共通のプロジェクトに存在し、名前空間にキー設定されたそれ自体のハッシュテーブルを含むシングルトンオブジェクトを探し、それぞれのプロパティクラスを作成します。

依存性注入は、それを行う良い方法でもあります。

メモリ内のプロパティへの静的ポインタがあると、より快適に感じることができます。実行時にプロパティを再読み込みしたい場合や、静的参照を使用して簡単に実装できる他の機能を再読み込みしたい場合があります。

クラスは島ではないことを覚えておいてください。再利用可能なクラスには、コアをシングルトーン参照から解放するクライアントクラスを含めることができます。

インターフェースを使用することもできますが、やりすぎないようにしてください。

Approache 2は間違いなく優れています。

とにかく、他のクラスに設定オブジェクトを検索させないでください。 configオブジェクトで取得したconfigをオブジェクトを削除する必要があります。

Implの構成については、 apache commons configuration をご覧ください。 p>

だから、main（）であなたが持つことができる

MyObject mobj = new MyObject();
mobj.setLookupDelay(appConfig.getMyObjectLookupDelay);
mobj.setTrackerName(appConfig.getMyObjectTrackerName);

代わりに

MyObject mobj = new MyObject();
mobj.setConfig(appConfig);

appConfigは、構成ファイル内の値の名前に基づいて値のすべてのルックアップを実行するApache構成ライブラリのラッパーです。

これにより、オブジェクトが非常に簡単にテスト可能になります。

しばらくJavaを実行しませんでしたが、プロパティをjava.lang.Systemプロパティに入れることはできませんか？この方法により、どこからでも値にアクセスでき、「グローバル」を回避できます。プロパティクラス。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top