0

だから私は次のようなクラスを持っています:

public class HBaseUtil {
    private final String fileName = "hbase.properties";
    private Configuration config;

    private HBaseUtil() {
       try {
         config = new PropertiesConfiguration(fileName);
       } catch (ConfigurationException e) {
         // some exception handling logging
       }
    }

    // now some getters pulling data out of the config object

    public static String getProperty(String fieldKeyName) {...}

    public static String getColumnFamily(String fieldName) {...}

    // ... some more getters

    // NO setters (thus making this a read-only class)
}

したがって、基本的に私はシングルトン クラスを自分用に持っています。これは、初めて使用するときに構成オブジェクトをセットアップし、その後は単純に get 呼び出しをリッスンし続けます。このクラスにはいくつかの問題があります。

  1. クラス HBaseUtil 内の静的メソッドの単体テストは、Singleton と構成ファイルの間の緊密な結合により困難になります。
  2. 私が本当に欲しいのは、ファイル名/ファイル名 + パスをクラスに提供して、そこに移動し、そのファイルから構成プロパティを読み取り、着信読み取り要求にそれらを提供できるようにすることです。ただし、ここで重要な注意点が 1 つあります。JVM の起動ごとに 1 回だけプロパティ ファイルを指定するという柔軟性が必要です。だから私は確かに状態を維持する必要はありません。

これが私が思いついたものです。シングルトンの代わりに、すべての静的メソッドを持ち、明示的なコンストラクターが定義されていない通常のクラスがあります。

public class HBaseUtil {
    // directly start with getters
    public static String getProperty(Configuration config, String fieldKeyName) {...}

    public static String getColumnFamily(Configuration config, String fieldKeyName) {...}

    // ...and so on
}

そして、次のように他のコードでクラスを使用する代わりに:

HBaseUtil.getProperty(String fieldKeyName)

私はそれを次のように使用します：

Configuration externalConfig = new PropertiesConfiguration("my-custom-hbase.properties");

HbaseUtil.getProperty(externalConfig, fieldKeyName)

私の質問:

  1. 私は正しい方向に考えていますか？私の要件は、JVM ごとに 1 回だけクラスに柔軟性を持たせることです。このために私のプロジェクトで構成可能にする必要があるのは、HBase .properties ファイルの場所/内容だけです。シングルトンを持つことは、この要件に対してやり過ぎだと思っていました。
  2. 私の要件には、他にどのようなより良いアプローチがありますか (上記のポイントで述べた)?

ありがとう！

注:このStackOverflow のディスカッションを読みましたが、さらに混乱してしまいました。

4

1 に答える 1

2

すべての静的メソッドを回避し、代わりにそのライフサイクルを義務付けないクラスを設計する必要があります。これは、パブリック コンストラクターを持つ典型的な不変 POJO にすることができます。

その後、シングルトンとして必要な場合は、シングルトンとして使用します。テストの場合は、別の方法で使用してください。

通常、依存性注入はこれらの問題を解決するための推奨される手段です。構成オブジェクトのプルメカニズムをハードコーディングする代わりに、それを必要とする任意のクラスにオブジェクトを配信します。その後、配信する Bean を後で決定できます。

あなたはおそらく Spring を使用していないので (それ以外の場合は依存性注入がデフォルトになります)、依存性注入に対する非常に軽量で非侵入的なアプローチである Guice の使用を検討してください。

于 2014-07-19T08:32:55.873 に答える