2017-01-18 19 views
2

状況は次のとおりです。特定のクラスを使用して構成パラメータにアクセスしてアクセスするライブラリを使用しています。 configローダークラスは、いずれかのライブラリで実装されています。 私がやったことはされています。今、私はへの変更を適用せずに既存のライブラリは、私の互換性BetterConfigLoaderを使用したいJavaクラスを拡張し、既存のライブラリで拡張クラスを使用するように強制する

public class BetterConfigLoader extends OldConfigLoader { 
    ... 
} 

:それは私の要件に適合し、さまざまな設定ソースをロードすることができるように設定ローダークラスを拡張しますライブラリを再コンパイルする必要はありません。 これを達成するためのベストプラクティスの方法はありますか?

答えて

1

これは、ライブラリが構成クラスをどのように参照しているかによって異なります。彼らはハードコードnew OldConfigLoader().configure()を持っていますか?

または何らかの種類のSPI技術を使用していますか。 META-INF/services/ConfigLoaderという名前のリソースが存在するかどうかを確認し、存在しない場合にのみ、デフォルトの構成クラスに戻しますか?

このようなリソースをチェックする代わりに、システムプロパティをチェックすることもできます。 これらの場合、一致するSPIリソースを作成するか、システムプロパティを設定して特別なクラスを設定できます。

ハードコーディングされた参照の場合、あなたは不運です。

+0

ハードコードされた参照がありますか? – MiH

+0

@MiHライブラリのコードからの呼び出しの例はありますか?彼らは直接コンストラクタを呼び出すのですか、あるいは静的ファクトリメソッドを使用していますか?後者の場合、 'OldConfigLoader'コードを変更することができれば、静的ファクトリメソッドが' BetterConfigLoader'を返すようにすることができます。 –

+0

コンストラクタを呼び出します。私は実際にOldConfigLoaderのコードを変更したくないのですが、これは互換性のある既存のライブラリの一部です – MiH

0

OldConfigLoaderを拡張する代わりに、それを置き換えることができます。 OldConfigLoaderのソースコードから始めて、必要に応じて変更してから、バージョンパスが元のものより高くなっていることを確認してください。実装のクラス名が同じで、元のパッケージと同じパッケージにあることを確認してください。

+0

"あなたのバージョンがより高いことを確認してください" - これはどういう意味ですか?このクラスを "置き換える"ための唯一の方法は、CLASSPATHに**以前のバージョン**の前にクラス**の新しいバージョンを置くことです(http://stackoverflow.com/a/6935725/2235015参照)。環境によっては、これはOPのためには不可能かもしれませんが、依然として非常に悪い習慣です。 –

+0

ああ、分かりました - "classpathの上位"なので、先行しています。それでも、非常に悪い習慣。 –

+0

これを達成するためにカスタムクラスローダーを使用するとどう思いますか? – MiH

関連する問題