命名子類的最佳做法

Question

我經常遇到這樣的情況：我有一個由接口或類表示的概念，然後我有一系列擴展它的子類/子接口。

例如： 一個通用的 「DoiGraphNode」 A 「DoiGraphNode」 表示資源 A 「DoiGraphNode」 表示Java資源 A 「DoiGraphNode」 具有相關聯的路徑，等等等等

我可以想到三個命名約定，並會對如何選擇評論。

---

選項1：始終以概念的名稱開頭。

這樣：DoiGraphNode，DoiGraphNodeResource，DoiGraphNodeJavaResource，DoiGraphNodeWithPath等

臨：這是很清楚我處理，很容易看到我的全部

精讀的選項：不是很自然？一切看起來都一樣？

---

選項2：把特殊的東西放在開頭。

這樣：DoiGraphNode，ResourceDoiGraphNode，JavaResourceDoiGraphNode，PathBaseDoiGraphNode， 等等等等

臨：這是非常清楚的，當我看到它的代碼

缺點：發現它可能是困難的，尤其是如果我不記得名字了，缺乏視覺一致性

---

方法3：把特殊的東西，去除一些多餘的文本的

這樣：DoiGraphNode，ResourceNode，JavaResourceNode，GraphNodeWithPath

臨：不多寫入和讀取 缺點：看起來像CR * P，很不一致，可以與其他的名字

Answer 1

名稱它們到底是什麼。

如果命名它們很困難或模棱兩可，通常表明該類正在做太多（單一職責原則）。

爲避免命名衝突，請適當選擇您的名稱空間。

Personnally，我會使用3

Answer 2

使用任何你喜歡的衝突，這是一個主觀的事情。重要的是要明確每個類代表什麼，並且名稱應該是這樣的，繼承關係是有意義的。儘管如此，我並不認爲將姓名中的關係進行編碼並不重要。這就是文檔的用途（如果你的名字適合於這些對象，人們應該能夠很好地猜測什麼是繼承）。

對於它的價值，我通常使用選項3，然後從我的經驗看別人的代碼選項2可能比選擇更普遍1.

Answer 3

選擇三個來自繼承的概念邏輯如下。由於您正在專門研究接口或類，因此名稱應該顯示它不再使用基本實現（如果存在）。

有很多工具可以查看類的繼承關係，所以指示類的實際功能的簡潔名稱將比嘗試將太多類型信息打包到名稱中更遠。

Answer 4

你可以找到一個編碼標準文檔一些指導，比如有對C＃here的文檔■設計。

就個人而言，我更喜歡選項2.這是通常的方式在.NET Framework的名字及其對象。例如看看屬性類。它們都以屬性（TestMethodAttribute）結束。 EventHandlers也是如此：OnClickEventHandler是處理Click事件的事件處理程序的推薦名稱。

我通常會在設計自己的代碼和接口時嘗試遵循這一點。因此，一個IUnitWriter產生一個StringUnitWriter和一個DataTableUnitWriter。這樣我總是知道他們的基類是什麼，它自然地讀取更多。自行編寫代碼是所有敏捷開發人員的最終目標，因此它對我來說似乎很適合！

Answer 5

我通常命名類似於選項1，尤其是當類將被polymophically使用。 我的推理是，最重要的信息位列在第一位。 （即，子類基本上是祖先的事實， （通常）擴展名'添加'）。 我喜歡這個選項，因爲當排序類名稱列表時， 相關的類將一起列出。 也就是說我通常將翻譯單元（文件名）命名爲與 相同的類名，因此相關的類文件自然會列在一起。 類似地，這對增量搜索很有用。

雖然我傾向於在我的編程生涯中使用選項2早些時候，我避免它現在因爲你說它是「不一致的」，似乎沒有很正交。

我經常使用選項3時，子類提供了大量的擴展或規格，或者如果名稱將是相當長的。 例如，我的文件系統名稱類是從字符串 衍生而來，但他們大大延長了String類和有顯著不同 使用/含義：

Directory_entry_name從String中派生增加了豐富的功能。 從Directory_entry_name派生的File_name具有相當特殊的功能。 從Directory_entry_name派生的Directory_name也具有相當特殊的功能。

還與選項1一起，我通常是一個接口類，使用不合格的名稱。 例如我可能有一個類interence鏈：

• 文本（接口）
• Text_abstract（摘要（基峯）一般化類）
• Text_ASCII
• Text_unicode（特異於ASCII編碼的具體類） （具體類的Unicode編碼）

我寧願接口和抽象基類自動出現在排序列表中的第一個。