在去年和我的團隊的代碼基礎上，我注意到了一個穩定的命名約定。是否有處理命名時尚的最佳方式？
例如，有很多類被命名以表示它們是可以幫助您做某事的類。
下面是我發現的那些：
MyClassUtil
MyClassFactory
MyClassHelper
MyClassManager
MyClassService
它只是在我看來，隨着時間的推移人們想出了命名約定相對同樣的事情，所以不是擁有一切以一致的方式命名你結束了一個代碼庫，有一個每一個約定。所有新的東西都是基於最新的時尚命名慣例命名的，所以你幾乎可以根據當時流行的約定來判斷一段代碼的年齡。
對付這種趨勢的最好方法是什麼？這真的是一個問題嗎？隨着這些命名時尚流行起來，應該使用最新的時尚嗎？應該用新的命名約定重新命名所有現有項目嗎？還是應該接受這個品種是不可避免的？
他們似乎不是時尚......所有這些名字都暗示了這個班的目的，而這些目的是不同的。有了編程，它的名字都是這樣，而且應該非常仔細地選擇它們。該品種不需要逃脫。名稱因類別的用途不同而有所不同。
MyClassUtil - 一些與MyClass一起工作的實用程序，它沒有附帶。也許MyClass屬於你正在使用的庫，但是你經常使用一些更高級別的函數，並且你需要在某處放置它們。
MyClassFactory - 以抽象方式創建MyClass的實例。這使您可以編寫需要MyClass實例的代碼。它可以從MyClassFactory獲取這些新實例。這將允許工廠將來修改以提供MyClass的不同特定實現。也許在單元測試中，工廠只提供虛擬/模擬MyClasses。這意味着使用工廠的班級可以進行測試而無需更改，只需更改工廠，並且可以隔離正在測試的班級。
MyClassHelper -k，我可能會同意，也許這可以是更具體的。它可以幫助MyClass，但是什麼。也許這有點類似於MyClassUtil。但是，可能MyClassUtil是與MyClass一起工作的常規函數，而助手則使用特定的MyClass實例進行初始化，然後可以在該實例上執行操作。您需要爲每個想要幫助的MyClass添加一個新助手。
MyClassManager - 也許這處理一個MyClass實例池並存儲或編排它們。例如。在CommunicationsManager中，該類將處理與處理端口或連接（如以太網或串行）通信的類以及處理通過其發送通信協議以便傳輸數據包的類，以及處理這些數據包中的消息。
MyClassService -A服務可以爲你做事情，就像給定一個郵政編碼將其轉換成網格引用。通常服務可以解決許多特定的事情。通過郵編代碼示例，這個類可能會有一些實現可以與不同的網站進行交流來完成轉換。
上面給出的所有類名都表明了我與面向對象原理的顯着偏離。沒有辦法告訴「MyClassUtil」或「MyClassService」做什麼。它可能是任何東西。班級命名應具體，並應清楚地傳達班級的實際功能。這些都沒有。處理這種趨勢的最好方法是刷新面向對象的編程技巧並相應地命名類。
現在，這些示例可能指出應用程序體系結構中的這些類表示的功能，而您對「MyClass」的使用僅僅是運行時更加明確的某個佔位符，在這種情況下，I不會將這些視爲命名時尚，而是將其視爲類的本身功能的描述性指示，並帶有對應用底層體系結構的鬆散暗示。
那麼在什麼情況下會適用不同的命名約定。什麼時候應該使用助手vs管理員vs服務？ – mezoid 2009-02-09 00:28:55
同樣，這一切都取決於應用程序編程的架構。當您需要區分來自業務對象本身的域業務對象的體系結構支持時，後綴將是可接受的。 – 2009-02-09 00:38:50
我真的不看廠或服務如何適應於特定的時尚...
廠是一家集設計模式，如果類確實是一個工廠，然後它是一個非常貼切的名字。
如果某個類是Windows服務，那麼稱它爲服務有什麼問題？
除非您發現執行所有重命名重構的代碼過於昂貴，即使您確實想要這樣做，也沒有問題。
但在我的代碼庫中列出的作爲服務甚至不是「Windows服務」...通常會有像MyClassRetrievalService，MyClassGroupingService，MyClassSomethingElseService等... – mezoid 2009-02-09 00:23:59
如果這是無處不在的，團隊需要花一些時間研究面向對象設計：閱讀源代碼以備受好評的面向對象框架，關於設計模式或書籍的書籍，例如Evans「Domain Driven Design」。
「Util」和「Manager」通常是糟糕的設計 - 「代碼氣味」的症狀。 「Helper」在特殊環境（Rails應用程序）之外，也是非常根深蒂固的。
「工廠」和「服務」具有確切的技術含義，您可以檢查代碼以確定它是否符合這些設計模式。
一般的補救措施是與團隊坐下來，並明確討論你對這些命名方案有什麼好處，什麼是有意義的，什麼沒有意義，然後在接下來的幾個月內應用重構淘汰您所有決定的名稱的技術都是代碼氣味。
命名很重要。它不應該掉以輕心，也不是一個主觀的問題。誠然，對於給定的命名問題，通常有不止一個正確的答案。然而，很少有很多回答與之前的選擇一致，這是關鍵。
建議將名稱重命名爲更好的名稱並重構代碼，以便每個類都有明確的。要知道使用哪種名稱，請閱讀Tim Ottinger關於Meaningful Names的文章。
當一個類只做一件事時，給它一個描述性的名字通常很容易。像「經理」這樣的詞語含糊不清，可能表明這個班級有責任做這麼多不相關的事情，沒有一個簡單的名字能夠描述班級的功能。如果你只是通過查看班級名稱就可以知道班級的作用，那麼班級就有一個好名字。
爲什麼不使用靜態分析工具來幫助實施一組樣式和一致性規則？
如果你在。NET世界微軟提供了一個叫做StyleCop的工具
在你給的classname例子中，「MyClass」代表了一個實際的類名，這樣你就可以看到像「PersonnelRecordUtil」或「GraphNodeFactory」這樣的名字嗎？ MyClassFactory對於一個類來說是一個非常糟糕的實際名稱。
優秀的答案。我必須承認，我並不完全相信他們是時尚人士......但我在腦海中有一種嘮叨的疑問......因此是個問題。只要我知道每個名字都有不同的具體含義，那麼我就可以使用它來爲我創造的東西命名。 – mezoid 2009-02-09 00:46:56
無論命名是否在現場，至少有人會將通用代碼扔在普通的類中。 – 2009-02-09 02:31:39