7

我一直在思考关于 osgi 包中包结构的“良好实践”。目前，我们平均每个捆绑包有 8-12 个类。我的一项倡议/建议是有两个包裹；com.company_name.osgi.services.api（用于与 api 相关的类/接口（外部导出）和一个包 com.company_name.osgi.services.impl 用于实现（未导出））。这有什么好处和坏处？还有其他建议吗？

4

3 回答 3

6

您也可以考虑将接口放在 中com.company_name.subsystem，而实现则放在com.company_name.subsystem.implOSGI 特定代码中，如果有的话，可以放在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

总是在你的包名中有apiandimpl可能很烦人。如果有疑问使用impl但不使用api.

于 2009-03-26T21:53:24.657 回答
2

重要的不是类的数量，而是概念。在我看来，您应该在捆绑中包含一个概念实体。在某些情况下，这可能只是其他几个包含 100 个类的包中的几个类。

重要的是您将 API 和实现分开。一个包包含您的概念的 API，另一个包包含实现。像这样，您可以为定义良好的 API 提供不同的实现。在某些情况下，如果您想远程访问捆绑包中的服务（例如使用 R-OGSi），这甚至可能是必要的

然后，API 包由代码共享使用，实现包中的服务由服务共享使用。探索这些可能性的最佳方法是查看 ServiceTracker。

于 2009-03-26T20:57:54.990 回答
0

在您的情况下，您可以在同一个包中实现，但它的所有类都“包保护”。这样，您可以导出包，并且即使不使用 OSGi（但作为常规 jar 文件），外部也不会看到实现。

于 2009-03-27T08:43:35.263 回答