3

別のプラグイン (WidgetMaster と呼びましょう) のバージョン 1.0 に依存する Eclipse プラグインを作成しました。現在、WidgetMaster のバージョン 2.0 がリリースされており、私が使用していた多くのクラスのインターフェイスが変更されています。WidgetMaster の両方のバージョンをサポートしながら、プラグインの 1 つのバージョンを維持するにはどうすればよいですか?

これまでのところ、私が思いついたのは次のとおりです。

  1. WidgetMaster が提供するすべての機能の独自のインターフェイスを作成します。これは、使用していたすべてのタイプのラッパーも作成する必要があることを意味します。
  2. WidgetMaster のサポートされているバージョンごとに、そのバージョンの API に関して、インターフェイスとすべてのラッパー クラスを実装する Fragment プロジェクトを作成します。

現在、プラグイン コード全体で WidgetMaster クラスを使用しているため、これはかなりの量の作業になります。Fragment プロジェクトから特定のバージョンの WidgetMaster のみに依存する場合は、そのすべてを移動してラップする必要があります。また、ラッパーの 99% はバージョンごとに同じですが、それでも各フラグメントにコピーする必要があります。

これは正しいアプローチですか、それともこの状況を処理するためのより良い方法はありますか?

4

1 に答える 1

1

長期的な範囲で WidgetMaster プラグインのさまざまなバージョンに継続的なサポートを本当に提供したい場合は、アダプター パターンが正しい方法のように思えます。

サポート時間を短縮するには、プラグインを複製して、バージョン管理システムとそのマージ機能を活用します。WidgetMaster の最新バージョンを使用する別のブランチを作成します。したがって、2 つのバージョンのプラグインがあり、それぞれが異なるバージョンの WidgetMaster を使用し、特定のバージョンの API 呼び出しを呼び出します。将来のマージが API 呼び出しのカスタマイズを上書きしないように、すべての設定が完了したら、VCS にマージ解決が通知されていることを確認してください (例: oursgit merge を使用した戦略)。

2 つの異なるアプローチにはオーバーヘッドがありますが、時間は異なります。Adapter アプローチは初期オーバーヘッドが大きくなりますが、VCS アプローチはセットアップが速くなります。ただし、アダプターが実装されると、オーバーヘッドは最小限に抑えられますが、VCS アプローチには常にマージ オーバーヘッドがあります。

ちなみに、OSGi フラグメントは、WidgetMaster を使用するバージョンをセットアップするのに本当に最適なオプションなのだろうか (アダプター アプローチを選択した場合)。私は OSGi の専門家ではありませんが、OSGi サービス ファクトリを調べることで、適切なバージョンの WidgetMaster を入手できます。OSGi で依存性注入を達成するために明らかに進化した方法があります: Apache Felix Maven SCR Plugin、Blueprint Container、Apache Felix iPojo。この SOの質問は、OSGi の DI の問題をカバーしているようです。

幸運を！近いうちに同じような課題に直面するので、どのルートをたどるか知りたいです!

于 2013-11-05T18:08:44.510 に答える