面對物件的思考（二） (轉)

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

面對的思考（二）

  如今，面對物件方法幾乎成為了成功、先進、的代名詞。使用面對物件的方法設計和實現一個幾乎成為了開發者們的預設選擇。但是，這種方法是否已經真正取得了成功了呢？真的達到了在他產生時候宣稱的優勢呢？很顯然對於這樣的問題大多數人是迷惑，不能作出肯定的回答。面對物件的方法在軟體分析和設計方面仍然遇到了困難，這些困難主要有這些表現：
  1、抽象現實問題的方法不容易被開發者真正掌握。分解問題域中物件一般的思考方式有以下兩種，一種是抽象物件的性質，這種方法實際上就是物件繼承，第二種就是物件組合的方法。在經典的理論中認為物件的繼承是面對物件方法的實質，但是不符合大多數人的思維習慣。對於一個輪胎而言，人們更願把它看成輪箍、外胎、內胎等等結構的組合體，而不是抽象成這樣的層次關係，橡膠-〉含有金屬的橡膠-含有金屬的圓形橡膠-〉輪胎。
  2、分析到設計仍然不能平滑的過渡，在分析階段產生物件，往往有很多現實的名詞，這影響了設計者的思考，使他們不能關注物件在問題域中的關係，往往受到這些名詞其他含義影響。假定普通的企業管理中，分析作了人-〉公司職員-〉高階職員-〉經理的抽象，設計人員往往會被人、經理、高階職員這些名詞的影響，不能把這樣的現實物件很好的對映到結構中去，甚至會去定義人的姓名、年齡這些屬性，然而這些屬性在問題域中是不關心的，實際上在程式結構中人這個物件會和真正的人概念完全不一樣，之所以抽象這些物件實際上為了提取問題域中的靜態關係和動態關係，現實的名詞干擾了設計者。
  3、面對物件方法產生的軟體沒有完全實現宣稱的軟體複用和簡化維護的目標。在沒有完全採用抽象物件性質的方法的時候，實際上完全採用也是很困難的，大多數人習慣於把複雜的事物分解成一組組合的物件，把簡單的事物進行抽象，在這種情況下產生的軟體結構是複雜的，物件組合之間必然充滿了複雜的訊息，要進行重複使用和維護當然是不容易的。
  4、缺乏評價一個面對物件設計的標準，一個設計，或者說怎樣做出一個能夠實現軟體複用、降低軟體複雜性的設計，沒有很好的理論支援。這本身就是由於物件抽象的靈活性造成的，不同的人對同樣的問題完全會有不同的抽象方法，面對物件的方法不限制人們抽象的方法，或者說根本沒有一套抽象的方法。我說的是抽象，和物件組合對應。缺乏標準，也必然造成軟體複用困難。
  為了解決這些問題，很多人進行了迴歸，我要說一些大逆不道的話了。第一個概念把繼承分解為介面繼承和實現繼承，認為物件實際上是實現和宣稱的方法集組成的，在現實的設計活動中，他們找到了複用的好辦法，因為他們把介面和實現分離，這樣在透過同樣的介面就可以操縱不同的物件，而不用關心背後物件的細節，這樣降低了物件之間的關聯程度。第二個概念，儘量使用物件組合而不是繼承，在把繼承分解以後，就會很自然的發現，純虛的基類實際上成為了物件的介面，而且為了複用的方便，幾乎完全不要實現繼承，因為複用是物件本身，而不是用它的基類，所以定義一個良好的組合成為了關鍵，而且繼承也會為這種複用帶來麻煩。我把這種解決方法稱為迴歸，這是面對物件向結構化的迴歸，或者說結構化方法的延伸。在物件進行復用的時候，一般不使用已經成型的物件，而是使用基類，複用的是基類已經實現的方法，當然這樣做，需要深刻理解原作者的意圖。一個只有一個純虛基類的物件和一個模組有什麼差別呢？這是模組的複用。複用的只是介面，也就是一組定義，要實現支援同樣介面的不同物件，需要完全重新設計，實際上並沒有程式碼複用。他把實現的複雜性推給了後面的設計者。如果僅僅把介面複用當成分析，在實現這個藉口物件的時候仍然堅持實現繼承，也就是實現的時候仍然分層，那麼這當然是可取的，但是我看不出需要介面繼承的意義。在這種方法下，設計者更傾向於進行問題的功能分解，舉個例子，設計企業的管理系統，設計者很可能在這種思考方式的主導下，劃分成財務部，人事部，業務部。這完全背離了面對物件方法的初衷。
  大多數問題是複雜的，習慣總是明智的，把一個大的問題分解成小問題，在解決小問題的時候使用抽象的方法，可以說是一個很好的折衷，也是很有效率的。但是不能把整個問題都細化，或者說完全取消實現繼承，如果那樣我看不出這還是面對物件。我更願意看到結構化方法和麵對物件方法的融合，而不是了面對物件的概念行結構化的做法。在對於評價分層抽象，或者說分層抽象指導原則、，幾乎沒有，這不能說是完整的。就像氣宗和劍宗構成了華山派一樣，獨孤九劍好像是絕種的劍宗武功，雖然難煉，但是殺了嶽不群。