質問
osgiバンドル内のパッケージ構造に関する「グッドプラクティス」について考えてきました。現在、平均して、バンドルごとに8〜12のクラスがあります。私のイニシアチブ/提案の1つは、2つのパッケージを持つことでした。com.company_name.osgi.services.api(api関連のクラス/インターフェース(外部にエクスポートされる)および実装用の1つのパッケージcom.company_name.osgi.services.impl(エクスポートされない))。これの長所と短所は何ですか?他に何か提案はありますか?
解決
インターフェイスをcom.company_name.subsystem
に配置することも検討してください。また、com.company_name.subsystem.impl
での実装は、OSGI固有のコード(存在する場合)をcom.company_name.subsystem.osgi
で行うことができます。
同じインターフェースを複数実装している場合があります。この場合、次のように考えることができます-com.company_name.subsystem.impl1
とcom.company_name.subsystem.impl2
例:
ジェネラコディセタグプレ
この意味で、パッケージ構造はOSGiに依存しない可能性があります。後で別のコンテナーに移動する場合は、追加するだけです ジェネラコディセタグプレ
パッケージ名にapi
とimpl
が常に含まれていると、煩わしい場合があります。疑わしい場合は、impl
を使用しますが、api
は使用しないでください。
他のヒント
重要なのはクラスの数ではなく、概念です。私の意見では、バンドル内に1つの概念エンティティが必要です。場合によっては、これは数百のクラスを持つ他のいくつかのパッケージのほんの数クラスである可能性があります。
重要なのは、APIと実装を分離することです。1つのバンドルには、コンセプトのAPIと、もう1つの実装が含まれています。このように、明確に定義されたAPIにさまざまな実装を提供できます。バンドルからリモートで(R-OGSiなどを使用して)サービスにアクセスする場合でも、これが必要になる場合があります
APIバンドルはコード共有によって使用され、実装バンドルのサービスはサービス共有によって使用されます。これらの可能性を探る最良の方法は、ServiceTrackersを調べることです。
あなたの場合、同じパッケージに実装を含めることができますが、そのクラスはすべて「パッケージで保護」されています。このようにして、パッケージをエクスポートでき、OSGiを使用していない場合でも(ただし通常のjarファイルとして)、実装は外部に表示されません。