OSGiバンドルのパッケージ構造

Question

osgiバンドル内のパッケージ構造に関する「グッドプラクティス」について考えてきました。現在、平均して、バンドルごとに8〜12のクラスがあります。私のイニシアチブ/提案の1つは、2つのパッケージを持つことでした。com.company_name.osgi.services.api（api関連のクラス/インターフェース（外部にエクスポートされる）および実装用の1つのパッケージcom.company_name.osgi.services.impl（エクスポートされない））。これの長所と短所は何ですか？他に何か提案はありますか？

Answer 1

インターフェイスを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は使用しないでください。

Answer 2

重要なのはクラスの数ではなく、概念です。私の意見では、バンドル内に1つの概念エンティティが必要です。場合によっては、これは数百のクラスを持つ他のいくつかのパッケージのほんの数クラスである可能性があります。

重要なのは、APIと実装を分離することです。1つのバンドルには、コンセプトのAPIと、もう1つの実装が含まれています。このように、明確に定義されたAPIにさまざまな実装を提供できます。バンドルからリモートで（R-OGSiなどを使用して）サービスにアクセスする場合でも、これが必要になる場合があります

APIバンドルはコード共有によって使用され、実装バンドルのサービスはサービス共有によって使用されます。これらの可能性を探る最良の方法は、ServiceTrackersを調べることです。

Answer 3

あなたの場合、同じパッケージに実装を含めることができますが、そのクラスはすべて「パッケージで保護」されています。このようにして、パッケージをエクスポートでき、OSGiを使用していない場合でも（ただし通常のjarファイルとして）、実装は外部に表示されません。