我正在创建一些OSGi捆绑包。他们注册服务，也获得（当然使用）彼此的服务。
我决定使用ServiceTracker代替声明式服务。
在搜索有关此信息的过程中，我发现了两种跟踪服务的方法。
第一个是为每个服务创建自己的跟踪器类，该类扩展了ServiceTracker类并覆盖需要覆盖的方法。然后，在激活器类中创建此跟踪器类的新实例，为该实例提供捆绑包上下文并打开它进行跟踪。
另一种方法是为每个服务创建一个跟踪器类，该类实现ServiceTrackerCustomizer接口并覆盖需要覆盖的方法。然后在激活器类中，创建ServiceTracker类的新实例，并为其提供捆绑包上下文，需要跟踪的服务名称以及定制器类的新实例。然后打开它进行跟踪。
两种方法之间有什么区别吗？我会说不。在ServiceTracker javadoc中，我可以看到ServiceTracker类也实现了ServiceTrackerCustomizer接口。
您能否告诉我这两种方法的利弊？提前致谢。
最佳答案
这是我的原因：
子类ServiceTracker如果
您想对超类的构造函数参数进行硬编码。例如：硬编码类型或过滤器。在这种情况下，如果所有用户都应该知道应该使用哪个过滤器实例化跟踪器，那就太不好了。
您要覆盖（包装）ServiceTracker的打开，关闭或其他功能
您想扩展ServiceTracker的功能。例如：通过实现可基于Java泛型相等性对服务对象进行预过滤的实现
在以下情况下实现接口：
您希望将来会切换到其他ServiceTracker实施。 ServiceTracker是OSGi核心的附加组件，自5.0.0起，它只是核心规格的一部分。将来可以创建其他更有效的实现
您不想决定要覆盖哪些构造函数，因为从业务逻辑的角度来看，这些参数是灵活的。将来可能还会有更多标准ServiceTracker类的构造函数。如果将其子类化，则您的类将不支持这些构造函数
您想从ServiceTrackerCustomizer的实现中的另一个类继承子类
如果不直接使用ServiceTracker
声明式服务或其他Component Model可帮助您编写更简洁，更稳定的代码