很久以前，我讀過一篇文章（我相信是博客文章），這使我走在命名對象的“正確”軌道上：在程序中命名事物時要非常謹慎。例如，如果我的應用程序（作為典型的業(yè)務應用程序）正在處理用戶，公司和地址，則我將具有User，a Company和Address域類-可能會彈出a UserManager，a CompanyManager和a AddressManager來處理這些問題。所以，你可以告訴那些UserManager，CompanyManager和AddressManager做什么？不可以，因為Manager是一個非常通用的術語，適合您對域對象可以執(zhí)行的任何操作。我閱讀的文章建議使用非常具體的名稱。如果它是C ++應用程序，并且UserManager的工作是分配用戶并將其從堆中釋放出來，那么它將不會管理用戶，而是保護用戶的生死。嗯，也許我們可以將其稱為UserShepherd?；蛘?，也許UserManager的工作是檢查每個User對象的數(shù)據(jù)并用密碼對數(shù)據(jù)簽名。然后我們會有一個UserRecordsClerk?，F(xiàn)在，這個想法一直困擾著我，我嘗試應用它。并且很難找到這個簡單的想法。我可以描述這些類的作用，并且（只要我不會陷入快速而骯臟的編碼中）我編寫的類就是一件事。從描述到名稱，我想念的是一種名稱目錄，這是一個將概念映射到名稱的詞匯表。最終，我想在腦海中想到一個模式目錄（通常，設計模式很容易提供對象名稱，例如工廠）工廠-創(chuàng)建其他對象（取自設計模式的命名）牧羊人-牧羊人處理對象的生命周期，對象的創(chuàng)建和關閉同步器-在兩個或多個對象（或對象層次結構）之間復制數(shù)據(jù)保姆-幫助對象在創(chuàng)建后達到“可用”狀態(tài)-例如通過連接到其他對象等等等那么，您如何處理該問題？您是否有固定的詞匯表，是否在動態(tài)地發(fā)明新名稱，或者您認為命名不那么重要或錯誤？
3 回答
炎炎設計
TA貢獻1808條經驗 獲得超4個贊
在可能的情況下，我嘗試復制.NET框架中已經存在的名稱，然后在Java和Android框架中尋找想法。
似乎Helper，Manager和Util是您為協(xié)調類所附加的不可避免的名詞，這些類不包含狀態(tài)并且通常是過程性的和靜態(tài)的。另一種選擇是Coordinator。
你可以得到與名字特別紫色prosey，去之類的東西Minder，Overseer，Supervisor，Administrator，和Master，但正如我所說，我更喜歡保持它就像你正在使用的框架名稱。
您還可以在.NET框架中找到一些其他常見的后綴（如果這是正確的術語）：
Builder
Writer
Reader
Handler
Container
12345678_0001
TA貢獻1802條經驗 獲得超5個贊
我全都追求好名字，而且我經常寫關于選擇事物名稱時要格外小心的重要性。出于同樣的原因，在命名事物時，我也謹防隱喻。在最初的問題中，“工廠”和“同步器”看起來像是好名字。但是，“牧羊人”和“保姆”卻不是，因為它們是基于隱喻的。您代碼中的類實際上不能是一個保姆。您之所以稱其為保姆，是因為它照顧其他事情，就像現(xiàn)實生活中的保姆照顧嬰兒或孩子一樣。在非正式演講中這是可以的，但是（以我的觀點）在代碼中命名類（必須由誰知道誰知道誰來維護）是不好的。
為什么？因為隱喻是與文化有關的，通常也與個人有關。對您來說，命名一個班級“保姆”可能很清楚，但對于其他人來說可能不太清楚。除非您編寫的代碼僅供個人使用，否則我們不應該依賴于此。
在任何情況下，約定都可以構成或破壞一個隱喻。“工廠”本身的使用是基于一個隱喻，但是已經存在了一段時間了，并且在編程世界中目前是眾所周知的，因此我可以說使用它是安全的。但是，“保姆”和“牧羊人”是不可接受的。
- 3 回答
- 0 關注
- 586 瀏覽
添加回答
舉報
0/150
提交
取消