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繼承的實現導出

回答

相關問題