如果您有一个常见的eclipse / osgi代码平台，您可以在其上构建各种产品，您是否应该从公共代码继承激活器
E.g。
org.test.common.PluginActivator
org.test.common.ui.UIPluginActivator
org.test.product1.Product1PluginActivator
org.test.product1.ui.Product1UIPluginActivator
org.test.product2.Product2PluginActivator
org.test.product2.ui.Product2PluginActivator
我希望所有的UI激活器都从普通激活器继承，对于非ui激活器也是如此。启动方法都会调用超级... 但是我想知道这是不好的osgi / bundle练习还是会导致问题。
有没有人对此有任何想法/意见？
答案 0 :(得分：4)
如果孩子无法在没有父包的情况下运行（即它具有功能依赖性），则不会通过使Activator继承它来添加任何额外的耦合。
我要小心继承公共父级，除非插件已经有理由这样做，因为即使你只是继承了一些常量，你也会强制加载bundle。
答案 1 :(得分：0)
我假设您正在使用Eclipse RCP，否则我会推荐Spring DM（或iPOJO，Google Guice with Peaberry或Declarative Services，......）。这样你就不需要再次编写另一个bundle激活器了。
另一方面，我的团队使用共同的摘要BundleActivator来获取与RCP相关的包。对我来说，将中间束中的实际束激活剂增加耦合。
答案 2 :(得分：0)
我不会，我会认为一般滥用子类化（而不是严格地从OSGi的角度来看）。
恕我直言，最好是将激活器类本身保持最小（如代码和运行时性能足迹），主要是将实际工作 - 如果任意 - 分配给工人类。如果你必须继承任何东西，你可以用那些工人类来做。