2010-09-08 37 views
3

假設我正在製作一個新庫,Jokes,帶有一個小API。在使我的API簡單易用的利益,我把它放在基地命名空間:在哪裏保持內部課程?

namespace Jokes 

    --> public interface IJoker 
     --> string Joke(); 

    --> public static class Jokers 
     --> public static IJoker NewSlapstickJoker() 
     --> public static IJoker NewAbsurdJoker() 
     --> public static IJoker NewCheesyJoker() 

還有鬼的實現是內部:

--> internal class SlapstickJoker : IJoker 
--> internal class AbsurdJoker : IJoker 
--> internal class CheesyJoker : IJoker 

現在我敢肯定的請遵循下面的指導原則(有人可以驗證嗎?):

  • 不要從根名稱空間訪問子名稱空間中的類型。 (例如,System中的類型無法識別System.Drawing中的類型)。

此準則適用於內部類嗎?爲了避免污染我的根名字空間,我想把我的內部類放在Jokes.Internal。這意味着Jokes名稱空間(Jokers)中的一個類型將知道子名稱空間Jokes.Internal中的類型。這個可以嗎?

+0

是Jokers的一個小丑工廠嗎?如果是這樣,也許更改名稱 – 2010-09-09 00:00:20

回答

2

爲了避免污染我的根名稱空間,我想把我的內部類放在Jokes.Internal中。這意味着Jokes名稱空間(Jokers)中的類型將知道子名空間Jokes.Internal中的類型。這個可以嗎?

是的,沒關係。關於在名稱空間中沒有類型的主要指導依賴於「sub」名稱空間內的類型實際上更多關於公共API。內部類和僅由內部類型使用的名稱空間實際上是一種實現細節,並且不屬於任何類型的指導。

我會堅持一致的東西,你覺得是有道理的。使用內部命名空間似乎是合理的(儘管我可能會做類似命名空間Jokes.Implementations)。

此外,鑑於您的Jokers類正在構建新的實例,它基本上是一個工廠。你可能想要考慮命名更像JokerFactory的東西,以使這一點很明顯。對我而言,Jokers將暗示該類中將包含一個Joker實例的集合,而不是一組工廠方法。

+0

+1 JokerFactory – ChrisW 2010-09-09 00:46:49

1

命名空間服務幾個主要用途:

  1. 它們有助於避免不同的開發商,不同的組織類型的創建和共享之間的命名衝突。
  2. 他們幫助組織類型分組,以便更容易理解他們做什麼以及哪些類型相互關聯或一起使用。

現在到你的具體問題。引用內部命名空間中的外部命名空間類型並不是非常理想 - 但它也不是很糟糕。雖然我現在想不起來,但如果.NET框架中存在這種情況存在的情況,我不會感到驚訝。作爲一個通用的設計原則,在層中構建代碼是一個好主意;並且通常這些層的結構使得較少的「專用」代碼不知道更多的「特定代碼」。

命名空間嵌套是將更專業的類型與不太專業的類型分開的一種方式。所以命名空間System包含非常一般和廣泛適用的類型 - System.Drawing更專業化,幷包含與圖像和視覺處理有關的類型。

但是,您應該避免做的事情是使用名稱空間根據可訪問性對類型進行分組。這絕對是名稱空間的濫用 - 並且從長遠來看很可能會導致問題(特別是因爲擴大類型的可訪問性是很常見的 - 但改變它所屬的名稱空間可能非常困難)。在我看來,只要你在做什麼都一致,並且在命名空間之間有一種明顯的類型劃分,我認爲你會沒事的。

0

如果您按照您的建議進行操作並不重要,但我認爲避免使用「Jokes.Internal」命名空間會更好。我不會認爲內部類是「污染」你的根命名空間。

無論如何,我認爲使名稱空間與您的可見性聲明相匹配是絕對不正常的。

1

爲了避免污染你的根命名空間,我建議之一:

  • 聲明類publicinternal代替(讓他們對你的API的用戶不可見,大會外)

  • 申報然後爲嵌套的內部類Jokers(使得它們不是Jokers類的外部可見)

+0

如果可以的話,我建議將它們嵌入'Jokers'內。 – Timwi 2010-09-09 00:41:58