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

Question

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

アプローチ 1: すべてのクラスからアクセスできる静的な Properties オブジェクトをいくつか用意します。(欠点: 次に、一部のクラスは、アプリケーションのコンテキストから取り出された場合に一般性を失います。また、別のクラスに配置され、将来消える可能性のある静的オブジェクトへの明示的な呼び出しも必要としますが、そうではありません。正しいと思います、私は間違っていますか？）

アプローチ 2: プロパティをメインクラスによってインスタンス化し、他のアプリケーションクラスに渡す。(欠点: ほとんどすべてのクラスに Properties オブジェクトへのポインターを渡すことになり、非常に冗長で面倒になるようです。私はそれが好きではありません。)

助言がありますか？

score 7 · Accepted Answer

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

依存性注入の良い副作用は、コードがより簡単にテストできるようになることです。

score 2 · Accepted Answer

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

最近のプロジェクトで Singleton プロパティオブジェクトを使用してみました。その後、機能を追加するときが来て、Singleton を修正する必要があり、使用したすべての場所を見つけなければならなかったことを後悔しましたMySingleton.getInstance()。

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

明示的なセッターを使用することも役立ちます。

class MyConfig extends Properties {...}

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

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

score 2 · Accepted Answer

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

score 1 · Accepted Answer

構成マネージャーコンポーネントが必要なようです。これは、ConfigurationManagerClass.instance(). これはすべての楽しみをカプセル化します。または、Spring のような依存性注入フレームワークを使用することもできます。

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

score 1 · Accepted Answer

システムプロパティを使用できる簡単なものを探している場合は、すべてのクラスで利用できます。String 値を保存するか、「もの」のリストを保存する必要がある場合は System.Properties() メソッドを使用できます。これは、HashTable である「Properties」オブジェクトを返します。その後、必要なものをテーブルに格納できます。見栄えはよくありませんが、グローバルプロパティを簡単に設定できます。YMMV

score 0 · Accepted Answer

アプローチ2は間違いなく優れています。

とにかく、他のクラスにconfigオブジェクトを検索させないでください。オブジェクトの外側の構成オブジェクトで取得した構成をインジェットする必要があります。

構成Implのヘルプについては、apachecommons構成を参照してください。

したがって、main（）で

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

それ以外の

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

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

このようにして、オブジェクトは非常に簡単にテスト可能になります。

score 0 · Accepted Answer

メモリ内プロパティへの静的ポインターがあると、より快適になります。実行時にプロパティをリロードしたい場合や、静的参照を使用して実装しやすいその他の機能を使用したい場合があります。

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

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

score 0 · Accepted Answer

しばらく Java をやっていなかったのですが、プロパティを java.lang.System プロパティに入れることはできませんか? このようにして、どこからでも値にアクセスでき、「グローバル」なプロパティクラスを持つことを回避できます。

score 0 · Accepted Answer

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

依存性注入も良い方法です。

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

9 に答える 9

Related

Reference