物件導向程式設計的關鍵目標

banq發表於2012-12-05
物件程式設計
物件導向程式設計的關鍵目標Object Oriented Programming: A Critical Approach一文從物件導向的誕生原因，以及始祖SmallTalk語言特點，闡述了OO的關鍵。

作者認為，C++語言比C複雜多，正如Object Pascal相當比Pascal也複雜得多。Ruby作為新語言總算爭了口氣，但是他們都有優缺點，他們給予了細心的程式設計師建立良好可重用的程式碼，但是另外一方面，他們也能讓粗心的程式設計師寫出無法維護除錯的程式碼。

Smalltalk的一個關鍵點在其他語言中丟失了：狀態處理。一些OO語言可以隱藏物件的內部狀態，但是狀態的訪問不是透過方法，或者發訊息，而是可以從外部直捅到內部狀態(比如java中宣稱public 變數名)，語言應該讓物件的狀態獨立於他們被使用的程式碼，這才是Smalltalk的關鍵所在。

正如Smalltalk原理架構師之一Dan Ingalls所說：No component in a complex system should depend on the internal details of any other component.
一個複雜系統的元件不應該依賴其他元件的內部細節(banq注：還是邏輯分層原理所致)

如果一個物件的內部細節能夠被從外部訪問，如果程式設計師改變這些內部細節，這些改變就會產生無法預料的副作用。程式設計師們經常認為封裝是可以保護程式碼避免出錯的，其實錯了，只有你執行嚴格的模組化和資料隱藏，以確保你的物件的內部細節對於物件之外的程式碼是不可見的。

Dan Ingalls再次強調了模組化的重要性:

"訊息傳送者能夠提供模組化，帶有內部細節的訊息從方法中被髮出，被接受者接受。結構化資訊同樣能夠被保護，因為所有對物件內部狀態的訪問都必須透過同樣的訊息介面。"

Alan Kay也表示歉意，他過分強調“物件”的好處而犧牲了突出“訊息”。他說：“對不起，我很久前就創造了這個”物件“這個詞，它讓很多人把重點放在較小的想法。大的想法是“訊息”......偉大的，不斷增長擴充套件的系統的關鍵是它的模組設計如何溝通，而不是其內部的屬性和行為應該是什麼。“


最後，作者總結：
現在，哪怕最現代的物件導向程式語言總是從Smalltalk隨機拾起一堆東西而忘記了什麼是Smalltalk的美麗。因此，這些語言相比舊語言來說，往往並不是最簡單的或更安全或更優雅和美麗。(banq注：方向錯了)

Alan Kay艾倫·凱說，“當C ++就出來了，他們試圖以迎合C + +程式設計師，他們做了一個不倫不類的系統。而正是這些不倫不類卻被稱為物件導向。“

這並不意味著用現代的物件導向的語言你不能寫出漂亮的，模組化的程式碼。但是，為了做到這一點，你必須運用了大量的自律(而這增加複雜，不再簡單了)，簡約就是美。

[該貼被banq於2012-12-05 10:20修改過]

相關文章