用 OSGi 应用程序开发和工作的最佳实践

核心提示： 客户端是完全从实现中分离出来了，正如在静态工厂方法模式中那样，用 OSGi 应用程序开发和工作的最佳实践(9)，此外：API 是完全从所有实现中分离出来了，正如 OSGi 服务层与实现合作应对实例创建，这是因为同样的理由，一个 OSGi bundle 应该是封装良好、高度聚合和松耦合的 &mda

客户端是完全从实现中分离出来了，正如在静态工厂方法模式中那样。此外：

API 是完全从所有实现中分离出来了，正如 OSGi 服务层与实现合作应对实例创建。

用于决定哪个实现将要返回的算法是贯穿所有 API 的而不是特定于某一个 API，就像在非 OSGi 系统中使用的静态工厂方法模式那样。

OSGi 服务注册表是一个共享服务的动态机制，其中服务可以在运行时自由来往。在服务可用时，Blueprint 通过将一个请求服务注入客户端 bundle 的 bean 中，帮助客户处理这种动态性。服务不可用时，Blueprint 可以注入另一个实现（如果有一个已注册的）。

7. 好的 bundle 就像构造良好的类：松耦合、高聚合

编写 bundle 时，将功能限制到一个特定的任务。将一个 bundlle 执行的任务数量降到最低，尝试尽量少的依赖。

原因如下

编写一个 OSGi 应用程序时，总想向一个已有 bundle 添加更多的功能，而不是去编写一个新的 bundle 。然而，这很快就会产生一个大且聚合性低的 bundle，通常会导致 bundle 导入和导出大量的包。使用 Require-Bundle 头部隐藏大量包导入并不是一个好的实践，因为这只不过是在 bundle 之间添加紧耦合。随着 bundle 依赖图的增长，必须下载和安装的 bundle 数量不断增多，通常成指数增长。这称之为 “hairball 效应” 。一个设计不佳的 bundles 需要在您的应用程序中下载并安装数十甚至上百兆，而仅仅能访问一到两个简单的功能，而一个高聚合的 bundle 只有极少的依赖性，一个很小的依赖树，而且更容易在其他应用程序中重用。需要注意该最佳实践为面向类设计对象镜像最佳实践，这是因为同样的理由。一个 OSGi bundle 应该是封装良好、高度聚合和松耦合的 — 就像一个格式良好的类 — 防止其依赖特定版本的其他 bundle 或类，并增加重用机会。