コンストラクターに触れたり、専用のフィールドやセッターを追加したりする必要はありません
それは依存性注入パターンではありません。リソース ロケーター パターンを代用することもできますが、それを適切に (特に、テスト容易性を維持する方法で) 行うことは簡単ではありません。セッターを使用すると、テスト対象のクラスを簡単に再構成できます。そのクラスが構成ファイルに依存している場合、単体テストの設定を変更する必要があるときはいつでも別の構成ファイルを作成しますか? 構成クラスをモックしますか? 可能ですが、正確ではありません...
プロパティ ファイル TEMPLATE を自動生成する機能
コメントですでに指摘されているように、古い構成ファイルを移行できないため、これはあまり役に立ちません。
スレッドセーフな方法で実行時に構成を更新する機能
一般に、構成されているコンポーネントからのサポートが必要です (たとえば、スレッド プール サイズの設定を変更するには、ワーカー スレッドの開始/停止が必要です ...)。一般に、それを処理する唯一の簡単な方法は、アプリケーションを再起動することです...
これらの要件を削除すると、Spring のPropertyOverrideConfigurerがうまく適合します。
または、サーブレット コンテナー内で実行する場合は、Spring 構成にJNDI ルックアップを追加できます。
本当にテンプレートを生成したいのであれば、私は既成の解決策を知りません. 私は次のようなことをするかもしれません:
class Configuration {
int threadCount = 10;
String secretKey;
@Description("Number of workers. Default value is number of available cores.")
int workerThreadCount = Runtime.getRuntime().availableProcessors();
/** Use default settings */
Configuration() {
}
/** read the settings from the file */
Configuration(Properties props) {
for (String prop : props) {
Field f = getClass().getField(prop);
f.set(this, props.getValue(prop));
// TODO: type conversion,
// e.g. with PropertyEditors,
// or Spring's ConversionService,
// or invoking the constructor that takes a single string argument,
// or ...
}
}
void save() {
for (Field f : getClass().getFields()) {
// TODO save the setting
}
}
}
デフォルトの設定を書くのは簡単でnew Configuration().save(file)
、既存の設定を「new Configuration(file).save(file)」のように簡単にアップグレードできます。
あなたのアプローチとは異なり、このアプローチは静的に型安全であり、冗長な型指定子を使用して構成設定にアクセスするコードを混乱させません。つまり、代わりに
if(config.value(Prop.PROXY_ENABLED,Boolean.class)){
あなたは単に書くことができます
if (config.proxyEnabled) {
また、フィールドはブール型 (ブール型ではない) になる可能性があるため、ここで NullPointerException が発生するリスクさえありません。