java - 跟踪 OSGi 服务时，扩展 ServiceTracker 类和实现 ServiceTrackerCustomizer 接口(interface)之间有区别吗？

Question

我正在创建一些 OSGi 包。他们注册服务并获取(当然还有使用)彼此的服务。

我决定使用 ServiceTracker 而不是声明式服务。

当我搜索相关信息时，我发现了两种跟踪服务方法。

第一个是为每个服务创建一个自己的跟踪器类，它扩展 ServiceTracker 类并重写需要重写的方法。然后在激活器类中创建该跟踪器类的新实例，为其提供 bundle 上下文并打开它进行跟踪。

另一种方法是为每个服务创建一个跟踪器类，它实现 ServiceTrackerCustomizer 接口(interface)并重写需要重写的方法。然后在激活器类中创建 ServiceTracker 类的新实例，为其提供捆绑上下文、需要跟踪的服务的名称和我们的新实例定制器类。然后打开它进行跟踪。

这两种方法有什么区别吗？我会说不。在 ServiceTracker javadoc我可以看到 ServiceTracker 类还实现了 ServiceTrackerCustomizer 接口(interface)。

您能告诉我这两种方法的优缺点吗？提前致谢。

Answer 1

这是我的理由:

子类ServiceTracker如果

• 您想要对父类(super class)的构造函数参数进行硬编码。例如:对类型或过滤器进行硬编码。在这种情况下，如果所有用户都应该知道应该使用什么过滤器实例化跟踪器，那就不太好了
• 您想要覆盖(包装)ServiceTracker 的打开、关闭或其他功能
• 您想要扩展 ServiceTracker 的功能。例如:通过实现基于 Java 泛型相等性来预过滤服务对象

实现该接口(interface)，如果:

• 您希望将来切换到其他ServiceTracker实现。 ServiceTracker是OSGi核心的附加组件，自5.0.0以来它只是核心规范的一部分。将来可以创建其他更有效的实现
• 您不想决定要重写哪些构造函数，因为从业务逻辑的角度来看，参数是灵活的。将来可能会有更多标准 ServiceTracker 类的构造函数。如果您对其进行子类化，您的类将不支持这些构造函数
• 您希望在 ServiceTrackerCustomizer 的实现中从另一个类派生子类

如果出现以下情况，请勿直接使用ServiceTracker

• 声明性服务或其他 Component Model帮助您编写更清晰、更稳定的代码