1

如果你有一个通用的 eclipse/osgi 代码平台，你可以在上面构建各种产品，你可以/应该从通用代码继承激活器吗？

例如

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 实践或可能导致问题。

有人对此有任何想法/意见吗？

4

3 回答 3

4

如果孩子在没有父包的情况下无论如何都无法运行（即它对它有功能依赖），那么您不会通过让 Activator 继承它来添加任何额外的耦合。

我会警惕从一个共同的父级继承，除非插件已经有理由这样做，因为即使你只继承了一些常量，你也会强制加载包。

于 2009-08-19T16:46:21.847 回答
0

我假设您正在执行 Eclipse RCP，否则我会推荐 Spring DM（或 iPOJO、带有 Peaberry 的 Google Guice 或声明式服务......）。这样你就再也不需要编写另一个捆绑激活器了。

另一方面，我的团队使用了与BundleActivatorRCP 相关的捆绑包的通用摘要。对我来说，将实际的捆绑激活器放在中央捆绑包中会增加耦合。

于 2009-08-24T21:13:31.850 回答
0

我不会，我实际上会认为这是对一般子类化的滥用（而不是严格从 OSGi 的角度来看）。

恕我直言，最好的办法是保持激活器类本身最小（如在代码和运行时性能足迹中），主要将实际工作（如果有的话）委派给工作类。如果你必须对任何东西进行子类化，你可以用这些工人阶级来做到这一点。

于 2011-02-01T16:45:08.580 回答