面對物件的思考 (轉)

面對物件的思考 (轉)[@more@]

面對的思考

 :namespace prefix = o ns = "urn:schemas--com::office" />

在比較老一些的討論面對物件方法的書籍中，都把繼承看成了最為關鍵的部分。一般認為，面對物件的方法中最為核心的部分就是繼承，因為從繼承的角度思考問題，是和結構化設計最為明顯的區別。如果，物件都沒有繼承，那麼物件和傳統的模組的概念沒有太多的差別。我並不是要把這兩種方法對立起來，我只是認為面對物件的方法背後的思想是應該和傳統結構化的方法有所區別的。

在結構化的方法中，我們首先需要考慮的是整個的功能，然後按照一些基本的模組劃分的原則，比如高內聚，松耦合，還有模組的扇入扇出數等等，把整個軟體的功能分解為各個模組的子功能。當然，模組一般認為是黑箱的。在設計階段需要定義的是各個模組的規則，我不想說是介面，介面我想用在下面另外一個地方。在完成了所有的模組的設計後，拼裝好，就應該能夠實現整個軟體的功能了。當然這屬於自頂向下的設計。這種思考的方式應該說是很自然的，就像搭積木一樣，也和我們平時的思維習慣相一致，他不是探究為什麼會有這樣的功能，而是思考我如何實現這樣的功能，當然我們的目標就是如何實現，但是他的思考方式是很直接的。這種方式有很大的侷限性，一是需求分析總不是很明確，也永遠不可能很明確，這就需要經常的變化原來的軟體功能構想，這帶來了麻煩，因為需要修改各個模組的設計，有時候甚至是致命的，會造成原來的設計被完全推翻。這需要一個很有的設計師，他必須瞭解這個軟體適用行業的業務，必須瞭解未來的軟體發展趨勢，並且要能夠預測可能的需求變化，這種要求是相當高的，一個設計師的水平就往往決定了一個軟體的生存時間，就算他有一個很好的團隊，他的拙劣設計仍然會使這個軟體成為曇花一現。二是結構化設計帶來的漂亮的文件，仍然不能為以後的維護工作帶來相當的好處，大多數的維護工作都是由於使用者的需求發生變化引起的，漂亮清晰的文件雖然能給後來的維護者很大的幫助，卻仍然不能減少他們的工作量，維護者在改動的時候仍然需要全面準確的理解原來設計者的意圖，否則就算有好的文件，維護工作仍然會帶來大量的錯誤，特別是在使用者需求發生大的變化的時候。在最近有了一些變化，我會在後面討論。

面對物件的方法在開始的時候，第一個工作就是識別物件，識別在問題域出現的物件，最經典方式是尋找需求說明書中出現的名詞，這是有道理的，語言是思維的外殼，這些名詞在我們頭腦中的概念決定了他們之間的聯絡，這種方式是偷懶的也是最自然的方式。第二步是尋找這些已經確定了的物件之間的共性，當然我們尋找的物件集應該是能夠涵蓋整個問題的了。尋找共性就是確定它們的共同祖先，在這個過程中設計師能夠對問題有進一步的清晰的瞭解。第三步就是確定問題中各個物件之間的關係，也就是它們之間的訊息傳遞，這不是指中視窗的訊息，呵呵。這個過程是苦難的，因為要確定各個物件之間的關係，也就是要更加精確的描述原來的問題，但是也是靈活的，就算理解出現了偏差，仍然是可以愉快的加以改正，因為我們是在理解物件，而不是分解功能，注意，我強調的是理解，而不是設計。這時候我們就可以提交我們的初步成果給客戶使用了，有問題的時候加以修改，這種修改不會很困難，因為我們不是基於功能分解，而是基於理解問題域中的物件概念。我們不太會把所有的物件都理解錯誤，理解錯的只是一個或者很少的一部分物件。我認為面對物件方法的實質在於迫使設計師從為什麼的角度來設計軟體，而不是很直接的怎麼做，在這種理解過程中，很自然的形成了我們的設計方案。在這個機制中，能夠起到關鍵性作用正是繼承，他是連線為什麼到怎麼做的橋樑，他自然和不自覺的就把設計師對問題的理解變成了解決問題的方案。之所以會這樣，那是因為，在現實世界中我們早就形成了解決這個問題的方法，我們需要的只是把這個解決方案轉換成的描述。我們在頭腦中的各種概念就是我們解決現實世界的各種問題留下的痕跡，他為我們解決類似的問題提供了參考，請注意到一個事實，科學研究就是想知道是什麼和為什麼，而不是要幹什麼，但是我們知道了是什麼和為什麼以後，我們就會知道要幹什麼。舉一個不恰當的例子，有一個工人很不滿他的工資待遇，於是有一個人跑來跟他說，你這麼少的工資待遇是因為我們國家還很困難，社會還在轉形，不可避免的要有一部分人作出犧牲，於是這個工人就很滿意了。為什麼這個工人會滿意？他原來要尋找的是解決他不滿工資待遇的途徑。其實，國家的概念在他的腦子中是神聖的，換一句話說，就是一種難以抗拒的力量，這是他的成長道路上教訓形成的，當他不尊重國家的時候，老師會罰站，然後那個人的話，就演變成，你現在無法抗拒國家的力量，你現在這種狀況是國家的意志，呵呵，這個工人知道怎麼做了，就是安於現狀。當然他不這樣認為，他的概念是我是崇高的。這有點像宗教哦，有點跑題了。不過的確，理解一個問題，實際上就是尋找解決問題的途徑。

在最近的一些日子裡，傳統的結構化的方法發生了變化，他開始吸收面對物件的概念，用於解決他的傳統問題，就是修改模組困難的問題。一方面，他形成一些經典的設計，幫助提高設計師在設計同類問題時的能力，如同建築中的經典設計結構，不過，這種幫助是有限的，我們很少見到一樣的建築物吧！另一方面，它使用介面的概念，意圖就是，使模組的實現和描述進一步的分離，這種好處在於，可以在一開始就設計靈活性很高的介面，使用模組是透過介面，這樣做實際上把總體設計的負擔進一步減輕，他把責任推給了介面實現者，因為在結構化的方法中靈活和精確始終是矛盾的。很多人把這種變化看成是面對物件方法的延伸，而我始終堅持認為：面對物件的方法是尋找是什麼和為什麼的過程，結構化的方法永遠是尋找做什麼和怎麼做的過程。