0

私たちは複数の開発者と一緒にプロジェクトに取り組んでおり、現在、構成ファイルからの値の取得はやや「ワイルドウェスト」です。

  • 誰もが文字列を使用して Config オブジェクトから値を取得します
  • これらのキーは、複数のクラスとパッケージに分散されています
  • 定数として宣言されていない場合もあります
  • キーの命名に一貫性がなく、構成ファイル (.properties) が乱雑に見える

私はそれを整理し、全員に構成キーを明示的に定義するよう強制したいと思います。構成キーが実際にどのように見えるかを合理化するために、理想的には 1 か所にまとめます。

Enum をキーとして使用し、取得方法を次のように変更することを考えていました。

getConfigValue(String key)

のようなものに

getConfigValue(ConfigKey)

注:Preferences API は私には少しやり過ぎに思えるので、このアプローチを使用しています。また、実際には単純なファイルに構成を入れたいと思っています。

このアプローチの短所は何ですか？

4

3 に答える 3

1

まず、FWIW、それは良い考えだと思います。しかし、「短所」とは何かを具体的に尋ねたので、次のようになります。

最大の「短所」は、構成データを使用する必要があるクラスをクラスに結び付けることConfigKeyです。作業中のコードに文字列を追加することを意味する構成キーの追加。これは、作業中のコードにenum とを追加することを意味します。これは（わずかに）より多くの作業です。

getConfigValueの一部であるクラスは、 enum.

于 2012-05-18T13:04:15.557 に答える
0

あなたの質問から、ラッパークラスがより良いAPIを提供することを意図して、生のJavaプロパティAPIのラッパークラスを作成するつもりであることは明らかです。これは良いアプローチだと思いますが、ラッパーAPIを改善すると思われることをいくつか提案したいと思います。

私が最初に提案した改善点は、構成値を取得する操作は1つではなく2つのパラメーターを取り、次の擬似コードに示すように実装する必要があることです。

class Configuration {
    public String getString(String namespace, String localName) {
        return properties.getProperty(namespace + "." + localName);
    }
}

次に、各開発者に、開発中のクラス/モジュール/コンポーネントの名前空間を示す文字列定数値を定義するように勧めることができます。各開発者が（どういうわけか）名前空間に異なる文字列定数を選択する限り、偶発的な名前の衝突を回避し、プロパティ名のある程度整理されたコレクションを促進します。

2番目に提案された改善点は、ラッパークラスがプロパティ値へのタイプセーフなアクセスを提供する必要があることです。たとえば、を提供しますが、、、、getString()などの名前のメソッドも提供getInt()します。バリアントは、プロパティ値を文字列として取得し、それを適切なタイプに解析しようとし、失敗した場合は説明的なエラーメッセージをスローする必要があります。このメソッドは、プロパティ値を文字列として取得し、たとえばカンマを区切り文字として使用して、文字列のリストに分割する必要があります。これを行うと、開発者がリスト値を取得するための一貫した方法が提供されます。getBoolean()getDouble()getStringList()int/boolean/doublegetStringList()

私の3番目に提案された改善は、ラッパークラスが次のようないくつかの追加メソッドを提供する必要があることです。

int getDurationMilliseconds(String namespace, String localName);
int getDurationSeconds(String namespace, String localName);
int getMemorySizeBytes(String namespace, String localName);
int getMemorySizeKB(String namespace, String localName);
int getMemorySizeMB(String namespace, String localName);

使用目的の例を次に示します。

cacheSize = cfg.getMemorySizeBytes(MY_NAMSPACE, "cache_size");
timeout = cfg.getDurationMilliseconds(MY_NAMSPACE, "cache_timeout");

このgetMemorySizeBytes()メソッドは、"2048 bytes"またはなどの文字列値"32MB"を適切なバイト数に変換する必要があり、getMemorySizeKB()同様のことを行いますが、指定されたサイズをバイトではなくKBで返します。同様に、メソッドは、、、および（たとえば、に変換される）getDuration<units>()などの文字列値を処理できる必要があります。"500 milliseconds""2.5 minutes""3 hours""infinite"-1

上記の提案は、尋ねられた質問とは何の関係もないと考える人もいるかもしれません。実際にはそうですが、卑劣な方法で。上記の提案により、開発者は「生の」JavaプロパティAPIよりもはるかに使いやすい構成APIを作成できます。彼らはそれを使用して、その使いやすさのメリットを得るでしょう。ただし、APIを使用すると、開発者に名前空間の規則を採用するように強制するという副作用があります。これは、対処したい問題の解決に役立ちます。

または、別の見方をすると、質問で説明されているアプローチの主な欠点は、勝ち負けの状況を提供することです。つまり、（開発者にプロパティの命名規則を課すことによって）勝ちますが、開発者は使い慣れたものを交換するために負けます。利点を提供しない別のAPIのJavaプロパティAPI。対照的に、私が提案した改善は、お互いに有利な状況を提供することを目的としています。

于 2012-05-18T21:25:55.967 に答える
0

統合のもう 1 つの欠点は、同じコード ベースの異なる部分に複数のプロジェクトがある場合です。開発時には、配信の依存関係に対処する必要があり、これが PITA になる可能性があります。

プロジェクト A とプロジェクト B がその順序でリリースされる予定であるとします。9 時間目に突然政治勢力が変化し、A の前に B を配信する必要があります。それに対処するために構成を再パッケージ化しますか? QA サイクルで再パッケージ化を処理できますか、それともタイムラインをリセットする必要がありますか。

典型的なリリースの問題ですが、管理しなければならないことがもう 1 つあります。

于 2012-05-18T13:58:51.767 に答える