多年以前（早在1992年），我加入了這個瘋狂的skunkworks項目，這個項目使用的是他們叫做Smalltalk的另類程序語言。“面向對象”作爲一個“熱門”項目纔剛剛起步。作爲“面向對象”的顧問，報酬非常可觀。很多人自以爲這就是新的對象派別的全部內容。直到5年前，Alan Kay發表了“我發明了‘面向對象編程’這個術語，但{Java和C++}跟我所知道的有所不同”的言論。（“I invented the term ‘Object Oriented Programming’ and this {Java and C++} is not what I had in mind.”）
在加入這個奇特的小組，使用這種奇怪的編程語言不久之後，我依然對實例變量、類變量、類實例變量之間的差別感到困惑。我參加了來自ParcPlace的Russ Pencin的培訓課程。他說了一些當時我很不喜歡的東西。儘管不明白金玉良言當中的要點，但我還是努力跟上進度。這需要多年的經驗才能漸漸體會其中的價值。建議的內容是：
不要使用‘er’結尾的對象（Don’t make objects that end with ‘er’.）
沒錯。面向對象編程（OOP）的模式在我們稱之爲“程序化編程”的文化當中活力十足。現在我們沒有過多地談論這兩種模式之間的對比。也許一部分是因爲面嚮對象語言現在俯拾即是。面向對象編程流派，在衆多派別中脫穎而出。可惜的是，我經常回想起我在2000年左右聽過Adele Goldberg的演講：“現在我們有很多面向對象編程技術，但就沒有那麼多面向對象編程的程序員”。假如我有一個建議想轉告給一羣有志成爲面向對象程序員的人，那應該是Russ提供的一句金玉良言：“不要使用‘er’結尾的對象。”
這名字到底意味着什麼呢？爲什麼值得人們對它如此興奮？多年以後我發現，面向對象編程的精髓在於將行爲綁定在數據上。在你還沒成爲他們無歸屬組織的重要一員時，程序就還是由行爲和數據構成。在典型的結構化程序設計之中，我們將精力集中在行爲（動詞）上，然後弄清楚我們需要哪些數據（名詞）才能執行。總而言之，我們將數據綁定在行爲上。但在面向對象程序設計之中，我們將程序的中心用名詞和數據表示，然後弄清楚我們要將哪些行爲綁定在他們之上，希望這些我們想要解決的問題能夠在突發的行爲中得到答案。
最近我覺得有一個更好的名字來形容一位同事差不多都插手過的每一個“er”對象例子。
給例子起一個更好的名字會讓設計更加具有獨立性，代碼的關聯性更少，總之，更加面向對象。這不是硬性規定，不過這會讓很多例子得到改善。
就拿某種“裝載程序模塊”來說吧，重點在於它的工作單元。模塊有許多實例變量，參數，也許還有很多到處傳輸的數據。如今，取而代之的是LoadRecord和LoadStream。我有理由相信，你們最終使用的工具，更類似於面向對象編程創始人心中設想的模樣。我們想要創造可以描述的對象，然後將某些行爲綁定在它上面，而不是將焦點集中在它的行爲上，然後弄清楚他們的行爲需要哪些數據。
某些以前學過的用er結尾的對象已經絕跡多年
管理者（Manager）——每當我遇到一位管理者時，我就會感到擔憂。大家沒有跟我說它的含義，卻早早地告訴我它的職能。它是註冊表嗎？那就叫它註冊表吧。是歷史記錄還是日誌？就那樣稱呼吧。是工廠嗎？就那樣稱呼吧。
控制器（Controller）——我在過去20年內只做過一個上等的控制器對象，它是一個象徵着現實世界對象的BallastVoltageController接口。事實上，世界上每一個簡單MVC的執行與控制器的不同作用本應告訴我們這個構想相當協調的事情。
組織者（Organizer以及許多類似的團體）——焦點在於他們的職能。這是一個用來說明讓衆多這種‘ers’對象轉化爲組織極其簡單的不錯例子。就把它們稱爲組織吧。現在我們來關注它們的內容。
分析器/渲染器/（Analyzer/Renderer）/等等——“勞動者”對象中定義清晰的例子。假設它們是用來分析/渲染/等等。
生成器/加載器/閱讀器/編寫器/（Builder/Loader/Reader/Writer/）等等——把焦點從被操控的對象身上挪開，它們自身往往承擔着重大的責任。
這樣一條路線規則也會有很多例外
有許多以‘er’結尾的名詞。註冊表、邊框、字母、數字。如果真的是一個名詞的話，那就好了。
有很多‘er’結尾的單詞，儘管重點在於它們的行爲上，也變得很常見了，所以我們最好至少在一定程度上維持這種情況。分部程序，編譯器，瀏覽器。
當你試圖建立一個以‘er’結尾的域對象模型時，我可以拿比較熟悉的人員管理域作例子，它可以提升個人素質，使人具有管理行爲。
你的經歷可能會有所不同，我相信有很多人持反對意見。直到你適應了這種心態一段時間之後，你才能真正體會到。爲你的項目/設計提供一個迴旋的餘地，看看會發生什麼。