7

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

4

3 に答える 3

6

インターフェイスを に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。たとえば、次のようになります。

com.company.scm        // the scm api
com.company.scm.git    // its git implementaton
com.company.scm.svn    // its subversion implementation
com.company.scm.osgi   // the place to put an OSGI Activator

この意味で、パッケージ構造は OSGi に依存しない可能性があります。後で別のコンテナーに移動する場合は、追加の

com.company.scm.sca     // or whatever component model you might think of

パッケージ名に常にapiとimplが含まれていると、煩わしい場合があります。疑わしい場合は使用しますが、使用implしないでapiください。

于 2009-03-26T21:53:24.657 に答える
2

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

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

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

于 2009-03-26T20:57:54.990 に答える
0

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

于 2009-03-27T08:43:35.263 に答える