2010-03-06 24 views
1

這將是確定把我的公共接口到自己的包(僅適用於我的組織)。確定把我的公共接口到自己的包

例如

com.example.myprogram - contains all normal code 

com.example.myprogram.public - contains public accessible interfaces 

com.example.myprogram.abstract - contains abstract classes 

這是一個好的或壞的事情,有什麼缺點?

回答

3

我根本不喜歡這種做法。根據功能,您應該對抽象和具體的類和接口進行分組。

討論Java API作爲一個例子。 Sun是否將Collections接口與實現分開了?不。孫的做法並不總是最好的指導,但在這種情況下,我同意。

不要這樣做。

0

我看不到作爲不好的做法,但你可能要考慮作爲替代組織每個邏輯功能,你的東西,而不是語法定義,這樣對於功能接口/抽象類/正常給定單位的所有代碼代碼進入相同的包。這是modular programming的原則之一。這樣說,根據項目的大小,將所有接口(但只包括那些接口)放在一個單獨的包中可能是必要的,如果你有一個基於純組件的插件體系結構,那麼可能會變得幾乎是必要的(所以其他模塊只知道接口,實際的實現是以某種方式動態注入的)。

0

公共接口系統模塊或系統之間的正式合同。因此,將它們與代碼的其餘部分隔離開來使它們脫穎而出是有意義的。

例如,在一個系統中,我的工作,系統的服務器和客戶端組件之間的所有公共接口被放置在一個特殊的系統模塊(叫,毫不奇怪,「API」)。這有很多的理想的效果,其中包括這些: - 語義,你知道去哪裏找,如果你需要對通信應該如何發生 任何種類的信息 - 你可以版本單獨的API模塊,這是非常有用的,當你不想移動的目標,即您簽署合同,提供支持「api v.1.1」的應用程序,而不是在別人改變界面的同時不斷播放catch,並要求您改編自己的一面

並不意味着您不應該在子包中進一步組織它們以區分它們的用途。 :)

總之,通過從其他代碼庫中分離接口來做正確的事情,儘管取決於您的特定需求,您可能會更好地進一步隔離接口獨立的系統模塊。

2

我可以建議你2種常用方法:

  1. 如果你真的認爲你的接口可以在未來更多的實現(即你的工作API)然後將它們移到一個單獨的模塊,並創建例如,有名稱爲「核心」的特殊軟件包。 (com.example.myprogram.core)。實現應該在相應的包中(如com.example.myprogram.firstimpl)。

  2. 如果您只有1個實現,那麼讓所有的接口都在com.example.myprogram包和所有具體類in com.example.myprogram.impl包中。