OSGi 包的包结构
我一直在思考有关 osgi 捆绑包内的包结构的“良好实践”。 目前，平均每个包有 8-12 个类。 我的倡议/建议之一是有两个套餐； com.company_name.osgi.services.api（用于api相关的类/接口（向外导出）和一个用于实现的包com.company_name.osgi.services.impl（不导出））。 这样做有什么优点和缺点？ 还有其他建议吗？
I've been thinking some about "good practice" regarding package structure within osgi bundles. Currently, on average, we have like 8-12 classes per bundle. One of my initiative/proposal has been to have two packages; com.company_name.osgi.services.api (for api-related classes/interfaces (which is exported externally) and one package com.company_name.osgi.services.impl for implementation (not exported)). What are the pros cons of this? Any other suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您还可以考虑将接口放在
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 无关，如果您稍后移动到不同的容器，则只需
在包名称中添加一个额外的“Alwayshaving api and
impl”可能会很烦人。 如果有疑问，请使用impl而不是api。You might also consider puting the interfaces in
com.company_name.subsystem, and the implementation incom.company_name.subsystem.impl, the OSGI specific code, if there is any, could be incom.company_name.subsystem.osgi.Sometime you might have multiple implementation of the same interfaces. In this case you could consider -
com.company_name.subsystem.impl1andcom.company_name.subsystem.impl2, for example:In this sense package structure could be OSGi agnostic, if you later on move to a different container, you just put an additional
Always having
apiandimplin your package name could be annoying. If in doubt useimplbut notapi.重要的不是类的数量，而是概念。 在我看来，你应该在一个捆绑包中拥有一个概念实体。 在某些情况下，这可能只是其他几个包含数百个类的包中的几个类。
重要的是，将 API 和实现分开。 一个包包含您的概念的 API，另一个包包含实现。 像这样，您可以为定义良好的 API 提供不同的实现。 在某些情况下，如果您想要远程访问捆绑包中的服务（例如使用 R-OGSi），这甚至可能是必要的。
然后代码共享使用 API 捆绑包，服务共享使用实现捆绑包中的服务。 探索这些可能性的最佳方法是查看 ServiceTrackers。
It's not the number of classes that is important but the concepts. In my opinion you should have one conceptual entity in a bundle. In some cases this might be just a few classes in other several packages with 100s of classes.
What it important is that you separate the API and the implementation. One bundle contains the API of your concept and the other the implementation. Like this you can provide different implementations for a well defined API. In some cases this might be even necessary if you want to access the services from a bundle remotely (using e.g. R-OGSi)
The API bundles are then used by code sharing and the services from the implementation bundles by service sharing. Best way to explore those possibilities is to look at the ServiceTrackers.
在您的情况下，您可以在同一个包中实现，但其所有类“包受保护”。 这样，您可以导出包，并且即使不使用 OSGi（但作为常规 jar 文件），外部也看不到实现。
In your case you could have the implementation in the same package, but all of its classes "package protected". This way, you can export the package and the implementation would not be visible to the outside, even when not using OSGi (but as a regular jar file).