私は、いくつかの異なるバージョンで出荷されるアプリケーションを作成しています (最初は、コード ベースの約 10 のバリエーションが存在し、維持する必要があります)。もちろん、コードの 98% 程度は異なるシステム間で同じであるため、コード ベースをそのままにしておくことは理にかなっています。
私の質問は - これを行うための好ましい方法は何ですか? たとえば、いくつかのバージョン (MyClassDifferent) で異なるクラス (MyClass) があり、そのクラスがいくつかの場所で参照されているとします。MyClassDifferent を参照するすべてのクラスを分割するのではなく、コンパイルしているアプリケーションのバージョンに応じてその参照を変更したいと考えています。プリプロセッサ マクロは便利ですが、コードを肥大化させます。また、概念実証の実装しか利用できないのでしょうか?
各アプリケーションの構成ファイルと組み合わせて、ファクトリ パターンのようなものを検討しています。誰にもヒントや指針はありますか？
あなたは正しい軌道に乗っています: 工場のパターン、構成など.
システム固有の機能を個別の jar ファイルに入れることもできます。そうすれば、コア jar ファイルと一緒に適切な jar を含めるだけで済みます。
私はあなたのファクトリーアプローチを支持し、Mavenまたはantを詳しく見てください（使用しているものに応じて）。パラメータ/プロファイルに基づいて使用されるクラスを決定するさまざまな構成ファイルを展開できます。
C/C++ のようなプリプロセッサ マクロは、Java では直接使用できません。ビルドスクリプトを介してこれをエミュレートすることは可能かもしれませんが。しかし、私はその道をたどりませんでした。私の提案は、工場のアプローチに固執することです。
幸いなことに、いくつかのオプションがあります
1) ServiceLoader (java6 に組み込まれている) は、MyClass のような API クラスを jar ファイルに入れ、この API に対してアプリケーションをコンパイルします。次に、/META-INF/services/com.foo.MyClass を使用して、MyClass の別の実装を別の jar に入れます。. 次に、jar の「配布」を維持するだけで、アプリケーションの複数のバージョンを維持できます。あなたの「メイン」クラスは ServiceLoader 呼び出しの集まりです
2) 1) と同じアーキテクチャですが、META-INF サービスを Spring または Guice 構成に置き換えます
3) OSGI
4) あなたの解決策
AbstractFactory 設計パターン、「依存性注入」、および「制御の反転」を参照してください。Martin Fowler は、これらについてここに書いています。
簡単に言うと、必要なすべてのコンポーネントを含む JAR ファイルを出荷します。カスタマイズ可能なサービス ポイントごとに、サービスのインターフェイスを定義します。次に、そのインターフェイスの 1 つ以上の実装を記述します。サービス オブジェクトを作成するには、AbstractFactory に要求します。たとえば、次のようになります。
AbstractFactory factory = new AbstractFactory();
...
ServiceXYZ s = factory.newServiceXYZ();
s.doThis();
s.doThat();
AbstractFactory 内で、Java リフレクション メソッド Class.classForName() および SomeClassObject.newInstance() を使用して、適切な ServiceXYZ オブジェクトを構築します。(このようにすることは、意味がない限り、jar ファイルに ServiceXYZ クラスを含める必要がないことを意味します。オブジェクトを通常どおりに構築することもできます。)
実際のクラス名は、各サイトに固有のプロパティ ファイルから読み込まれます。
独自のソリューションを簡単に展開することも、Spring、Guice、Picoなどのフレームワークを使用することもできます。