2017-09-27 8 views
1

私は以下のユーティリティクラスをJavaで持っています。Utilityクラスに変数を注入するのは良い方法ですか?

public class Utils { 
     private static Properties commonProps; 

     private Utils() {} 

     private static setCommonProps(Properties commonProps) { 
      Utils.commonProps = commonProps; 
     } 

     public static boolean staticMethod1() { 
      commonProps.get("xyz"); 
     } 

     public static void staticMethod2() { 
     } 
    } 

そして、私たちは春の機能org.springframework.beans.factory.config.MethodInvokingFactoryBeanの助けを借りて "commonProps" を初期化します。

このコードの設計に問題はありますか?これは悪影響を及ぼすことができますか? Utilityクラスに対してこのような変数の初期化を行うことをお勧めしますか?

注:ここでは、プロパティcommonPropsは単なるプレースホルダです。このクラスで使用する必要のある共通のメンバ。起動時に注入する必要があります。

答えて

1

静的フィールドに変更を加えないでください。それは反パターンです。また、Springを使用して静的フィールドを挿入しないでください。これらのことを行うことで、コードが扱いにくくなり、テストするのが非常に難しくなります。

すでに@Valueを使用して、Bean内のプロパティを持つフィールドを挿入することができます。これは動的ではありませんが、実際には動的プロパティを持つべきではありません(IMOでも可能ですが)。プロパティをスタートアップ定数などと考えてください。彼らは変わるべきではありません。

2

一般に、依存性注入は、テストが容易なより優れた設計につながるため、良いことです。あなたの特定のケースでは、達成しようとしているものを見なければなりません。

標準のJava Properties APIを使用してプロパティにアクセスし、値を追加するための単一のポイントを提供しようとしているようです。たとえば、getBoolean()に相当するものを指定します。

シングルアクセスポイントに関しては、スレッドの問題を考慮する必要があります。ただし、静的メソッドを使用する前にユーティリティクラスが設定されていることを保証できる限り、大丈夫です。

Properties APIの拡張に関しては、独自のライブラリを作成して管理するコストを犠牲にするよりも、既存のライブラリの1つを使用する方がよい場合があります。たとえば、私はApache Commons Configurationがかなり良いと判断しました。

+0

ここにcommonPropsは単なるプレースホルダです。このクラスの複数の関数で使用する必要のあるメンバーで、起動時に注入する必要があるメンバー。 – user3345334

関連する問題