適用於抽象類的許多具體實現的命名空間

Question

我正在設計.NET庫，我正在尋找有關類組織和命名空間的一些反饋。

假設我有一個抽象的Message類，它位於根名稱空間Foo 。 Message為不同的消息類型提供了許多具體實現。 鑒於將有許多具體的實現（讓我們假設20，甚至更多），是否期望這些具體類型存在於一個單獨的命名空間中，類似於Foo.Messages ？

我擔心使用太多具體的Message類來混淆命名空間，我的庫的用戶很少需要直接使用它們。 使用圖書館時你有什么期望？

編輯：

另外，如果我將具體類分組到Foo.Messages ，那么抽象類也應該存在於那里，還是應該保留在Foo ？

Answer 1

如果您的庫的用戶不構建您的具體實現類（它們通過工廠模式來獲取實例，並且僅通過抽象基類型訪問實例），請考慮使您的具體實現類內部。 這將使他們遠離用戶的代碼完成選擇。

在Foo.Messages命名空間下對所有具體實現類進行分組聽起來不錯。 你也不想在另一方面走得太遠 - 為小事創建大量名稱空間對用戶來說是一個巨大的刺激。

Answer 2

如果您正在創建一個庫並且您使用具有許多具體實現的抽象Message類，那么從庫的用戶隱藏所有具體實現並提供將返回抽象Message的Factory類的訪問通常是個好主意（返回類型，實際返回對象將是具體的當然），如果對於庫的客戶端來說是可以的，它通常是封裝為20個甚至更多的類，並以一種非常方便的方式提供對所需功能的訪問。

Answer 3

一種加載的問題，但如果問題是有太多的類妨礙了可發現性，那么解決方案的一部分可能是將這些類中的一些internal而不是public ？ 如果用戶不會直接實例化這些，那么這可能是解決雜亂問題的一部分。

它確實非常依賴於您正在設計的API的性質，並且在某種程度上取決於品味。 通常會有一個主要類或一組類，您的用戶將在大多數時間直接進行，例如NLog的Logger ，或AutoMapper的Mapper ，或NoRM的Mongo ，或一般的類工廠。 這些應該是前置和中心的，並且可以被發現，並且你可以強有力地證明最好在你的根命名空間中擁有它。

對於其他課程（更多關於實施而不是關於API的課程），顯然你想要有條理，但你可以放心地玩，並以一種讓你覺得自然的方式組織，只要部分用戶需要查找的API最明顯。 Foo.Messages似乎是一種完全合理的開始方式。 另一方面，如果90％的類都是Message子類，但是Server消息和Client消息或Purple消息和Plaid消息之間存在重要區別， Foo.Server或Foo.Plaid可能是適合您的命名空間類型。