我收到過最好的編程建議：別給物件取以「er」結尾的名字

源起：1992 年的 Smalltalk 培訓

Russ Pencin 一句話改變了我的工程師生涯：「Don't make objects that end with 'er'.」

當時我困惑於實例變數、類變數、類實例變數的區別，這句建議聽起來荒謬，但多年實踐證明它是物件導向設計精髓的縮影。

核心洞見：行為綁定數據，而非數據綁定行為

• 程序化思維：關注「動詞」（行為），再找「名詞」（數據）服務行為 → Manager、Controller、Processor、Loader。
• 物件導向思維：關注「名詞」（領域概念/數據），再將行為綁定在其上 → Order、Customer、Invoice、Shipment。

「er」結尾的類通常暴露了程序化殘留：它們往往是「做某事的工具」，而非「領域實體」。

重構實戰：從「er」到領域名詞

例外情況

• 本身就是名詞：Register（登記冊）、Border（邊框）、Character（字符）、Number（數字）。
• 行業慣用語：Compiler、Interpreter、Browser、Servlet——已成領域術語，無需強行改名。
• 領域模型需要行為豐富的實體：如 Employee（員工）可有 promote()、transfer() 等業務行為。

實踐建議

1. 命名時問自己：這是一個「東西」還是一個「做事的工具」？
2. 嘗試去掉「er」：看剩下的詞根是否能成為領域名詞。
3. 關注「有什麼」而非「做什麼」：類圖應呈現名詞網絡，方法才是動詞。
4. 給專案 2 週適應期：強制嘗試，觀察設計變化——耦合度下降、內聚度上升、測試更容易。

結語

「面向對象技術很多，但面向對象的程序員不多。」—— Adele Goldberg

這條簡單規則不是教條，而是通往真正 OO 設計的思維鑰匙。下次想寫 UserManager 時，停下來想想：它真的是 UserRegistry、UserProfile、AuthenticationService，還是單純的 User 加上行為？