osgi继承的实现导出

根据我在不同的地方（one example）阅读过的最佳实践，理想的是分离API和实现，但也仅仅导出API包中的包而不是实现包中的包，应该改为注册为服务。osgi继承的实现导出

但是我还不清楚你应该如何扩展一个具体的类。在我看来，要能够做到

class Child extends com.foo.ParentImpl { 
}

的IMPL捆绑将需要公开com.foo

AFAIU只有两种方式

出口的具体实施，但是这违反了最佳做法
永远不要从不同的包中扩展类。即将所有类型的层次结合在一起。在我看来，这种战略模块化框架的观点是错误的

那么这样做的正确方法是什么？

来源

2013-06-28 Hilikus

您可以将实现类公开为导出 - OSGi不会阻止您这样做。请注意您违反了最佳做法。

您可能会争辩说，最佳做法是打算被打破，在某些情况下，你会是对的。但是，这个确实存在的理由很充分！ Java中的继承创建了基类和子类之间非常紧密的耦合。通过允许其他bundle具有您的实现类的可见性并可能将它们子类化，那么严重会限制您在基类中进行实现更改的能力。实质上是的API，所以在将来不能更改。

所以我的建议是忘记继承。它被高估了。

如果你真的想这样做，然后继续层次在一起，按您选择号码2

来源

2013-06-28 20:37:45

谢谢尼尔。我也同意你的看法，继承被高估了 – Hilikus

TLDR：分离出API和执行最好留给你公开的事情，因为OSGI服务的实例实例将从捆绑引用。否则，请按照原样展示您的课程。

您在OSGI中获得的模块化类型不适合扩展Service类。您使用某种设计模式会更好，因为它可以让您扩展服务的功能。

我也想知道你想要扩展什么类，以及它的目的是什么。

现在，如果您绝对必须在服务包之外扩展服务级别，那么您最好的选择可能是委派。

class MyExtendedService implements Service { 
    Service service; 
    //delegate to MyService which also implements Service and 
    // is pulled from another osgi bundle. 
}

现在，如果你正在定义是“东西”，像模型或值对象的类，有可能是没有理由有单独的API和实现类。只是将它们暴露出来。

来源

2013-06-28 19:16:43

osgi继承的实现导出

回答

相关问题