我曾經得到的一個最好的程式設計建議

李盛暉發表於2011-11-28

多年以前(早在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’結尾的域物件模型時,我可以拿比較熟悉的人員管理域作例子,它可以提升個人素質,使人具有管理行為。

你的經歷可能會有所不同,我相信有很多人持反對意見。直到你適應了這種心態一段時間之後,你才能真正體會到。為你的專案/設計提供一個迴旋的餘地,看看會發生什麼。

 

英文原文:One of the Best Bits of Programming Advice I ever Got

相關文章