深入淺出OOD（一） (轉)[@more@]

深入淺出OOD（一）

撰文/to:%20gigix@umlchina.com">透明:namespace prefix = o ns = "urn:schemas--com::office" />

（本文首發於免費電子雜誌《C++ View》。）

有物昆成，先天地生。蕭呵！謬呵！獨立而不改，可以為天地母。吾未知其名，字之曰道。吾強為之名曰大，大曰逝，逝曰遠，遠曰反。道大，天大，地大，王亦大。

——《道德經》，第二十五章

不軟

從60年代的軟體危機，到今天傳統軟體工程方法處處碰壁的處境，都說明一個問題：軟體不軟（Software is Hard）[Martin, 95]。說實話，軟體是一塊硬骨頭，真正開發過軟體的人都會有此感覺。一個應用總是包含無數錯綜複雜的細節，而者則要把所有這些細節都組織起來，使之形成一個可以正常運轉的，這實在不是一件簡單的事。

為什麼會這樣？舉個例子來說：可以很輕鬆地說“我要一個字處理軟體”，他覺得“字處理軟體”這樣一個概念是再清楚不過的了，根本不需要更多的描述；而真正開發一個字處理軟體卻是一件困難無比的事情——我曾經親眼看到開發字處理軟體的人們是怎樣受盡折磨的。為什麼表述一個概念很容易，而實現一個概念很困難？因為人們太擅長抽象、太擅長剝離細節問題了。

軟體不軟，癥結就在這裡：使用者很容易抽象地表達自己的需求，而這種抽象卻很難轉化為程式程式碼。軟體不軟，因為很簡單的設想也需要大量的時間去實現；軟體不軟，因為滿足使用者的需求和期望實在太困難；軟體不軟，因為軟體太容易讓使用者產生幻想。

而另一方面，技術卻在飛速發展。從幾十年前神秘的龐然大物，到現在隨身攜帶的移動；從每秒數千次運算到每秒上百億次運算。當軟體開發者們還在尋找能讓軟體開發生產力提高一個數量級的“銀彈”[Brooks, 95]時，硬體開發的生產力早已提升了百倍千倍。這是為什麼？

硬體工程師們能夠如此高效，是因為他們都很懶惰。他們永遠恪守“不要去重新發明輪子”的古訓，他們儘量利用別人的成果。你看到有硬體工程師自己設計撥碼開關的嗎？你看到有硬體工程師自己設計低通濾波電路的嗎？你看到有硬體工程師自己設計計時器的嗎？他們有一套非常好的封裝技術，他們可以把電路封裝在一個接裡面，只露出介面。別人要用的時候，只管按照介面去用，完全不必操心接外掛內部的實現。

而軟體工程師們呢？在STL成為C++標準之前（甚至之後），每個C++程式設計師都寫過自己的排序演算法和連結串列，並認為自己比別人寫得更好……真是令人傷心。

OOD可以讓軟體稍微“軟”一點

軟體不軟，不過OOD可以幫助它稍微“軟”一點。OOD為我們提供了封裝某一層面上的功能和複雜性的工具。使用OOD，我們可以建立黑箱軟體模組，將一大堆複雜的東西藏到一個簡單的介面背後。然後，軟體工程師們就可以使用標準的軟體技術把這些黑箱組合起來，形成他們想要的應用程式。

Grady Booch把這些黑箱稱為類屬（class category），現在我們則通常把它們稱為“（component）”。類屬是由被稱為類（class）的實體組成的，類與類之間透過關聯（relationship）結合在一起。一個類可以把大量的細節隱藏起來，只露出一個簡單的介面，這正好符合人們喜歡抽象的心理。所以，這是一個非常偉大的概念，因為它給我們提供了封裝和複用的基礎，讓我們可以從問題的角度來看問題，而不是從機器的角度來看問題。

軟體的複用最初是從庫和類庫開始的，這兩種複用形式實際上都是白箱複用。到90年代，開始有人開發並出售真正的黑箱軟體模組：（）和（control）。框架和控制元件往往還受平臺和語言的限制，現在軟體技術的新潮流是用P作為傳輸介質的 Service，它可以使軟體模組脫離平臺和語言的束縛，實現更高程度的複用。但是想一想，其實Web Service也是面向，只不過是把類與類之間的關聯用XML來描述而已[Li, 02]。在過去的十多年裡，物件導向技術對軟體行業起到了極大的推動作用。在可以預測的將來，它仍將是軟體設計的主要技術——至少我看不到有什麼技術可以取代它的。

上面，我向讀者介紹了一些背景知識，也稍微介紹了OOD的好處。下面，我將回答幾個常見的問題，希望能借這幾個問題讓讀者看清OOD的輪廓。

什麼是OOD？

物件導向設計（-Oriented Design，OOD）是一種軟體設計方法，是一種工程化規範。這是毫無疑問的。按照Bjarne Stroustrup的說法，物件導向的正規化（paradigm）是[Stroustrup, 97]：

l  決定你要的類；

l  給每個類提供完整的一組操作；

l  明確地使用繼承來表現共同點。

由這個定義，我們可以看出：OOD就是“根據需求決定所需的類、類的操作以及類之間關聯的過程”。

OOD的目標是管理程式內部各部分的相互依賴。為了達到這個目標，OOD要求將程式分成塊，每個塊的規模應該小到可以管理的程度，然後分別將各個塊隱藏在介面（interface）的後面，讓它們只透過介面相互交流。比如說，如果用OOD的方法來設計一個-客戶端（client-server）應用，那麼伺服器和客戶端之間不應該有直接的依賴，而是應該讓伺服器的介面和客戶端的介面相互依賴。

這種依賴關係的轉換使得的各部分具有了可複用性。還是拿上面那個例子來說，客戶端就不必依賴於特定的伺服器，所以就可以複用到其他的環境下。如果要複用某一個程式塊，只要實現必須的介面就行了。

OOD是一種解決軟體問題的設計正規化（paradigm），一種抽象的正規化。使用OOD這種設計正規化，我們可以用物件（object）來表現問題領域（problem ain）的實體，每個物件都有相應的狀態和行為。我們剛才說到：OOD是一種抽象的正規化。抽象可以分成很多層次，從非常概括的到非常特殊的都有，而物件可能處於任何一個抽象層次上。另外，彼此不同但又互有關聯的物件可以共同構成抽象：只要這些物件之間有相似性，就可以把它們當成同一類的物件來處理。

OOD到底從哪兒來？

有很多人都認為：OOD是對結構化設計（Structured Design，SD）的擴充套件，其實這是不對的。OOD的軟體設計觀念和SD完全不同。SD注重的是資料結構和處理資料結構的過程。而在OOD中，過程和資料結構都被物件隱藏起來，兩者幾乎是互不相關的。不過，追根溯源，OOD和SD有著非常深的淵源。

1967年前後，OOD和SD的概念幾乎同時誕生，它們分別以不同的方式來表現資料結構和演算法。當時，圍繞著這兩個概念，很多科學家寫了大量的論文。其中，由Dijkstra和Hoare兩人所寫的一些論文講到了“恰當的程式控制結構”這個話題，聲稱goto語句是有害的，應該用順序、迴圈、分支這三種控制結構來構成整個程式流程。這些概念發展構成了結構化方法；而由Ole-Johan Dahl所寫的另一些論文則主要討論程式語言中的單位劃分，其中的一種程式單位就是類，它已經擁有了物件導向程式設計的主要特徵。

這兩種概念立刻就分道揚鑣了。在結構化這邊的歷史大家都很熟悉：NATO會議採納了Dijkstra的思想，整個軟體產業都同意goto語句的確是有害的，結構化方法、瀑布模型從70年代開始大行其道。同時，無數的科學家和軟體工程師也幫助結構化方法不斷髮展完善，其中有很多今天足以使我們振聾發聵的名字，例如Constantine、Yourdon、DeMarco和Dijkstra。有很長一段時間，整個世界都相信：結構化方法就是拯救軟體工業的“銀彈”。當然，時間最後證明了一切。

而此時，物件導向則在研究和教育領域緩慢發展。結構化程式設計幾乎可以應用於任何程式語言之上，而物件導向程式設計則需要語言的支援/editor/Editor.htm#_ftn1" name=_ftnref1>[1]，這也妨礙了物件導向技術的發展。實際上，在60年代後期，支援物件導向特性的語言只有Simula-67這一種。到70年代，施樂帕洛阿爾託研究中心（PARC）的Alan Key等人又發明了另一種基於物件導向方法的語言，那就是大名鼎鼎的Smalltalk。但是，直到80年代中期，Smalltalk和另外幾種面嚮物件語言仍然只停留在實驗室裡。

到90年代，OOD突然就風靡了整個軟體行業，這絕對是軟體開發史上的一次革命。不過，登高才能望遠，新事物總是站在舊事物的基礎之上的。70年代和80年代的設計方法揭示出許多有價值的概念，誰都不能也不敢忽視它們，OOD也一樣。

OOD和傳統方法有什麼區別？

還記得結構化設計方法嗎？程式被劃分成許多個模組，這些模組被組織成一個樹型結構。這棵樹的根就是主模組，葉子就是工具模組和最低階的功能模組。同時，這棵樹也表示結構：每個模組都呼叫自己的直接下級模組，並被自己的直接上級模組呼叫。

那麼，哪個模組負責收集應用程式最重要的那些策略？當然是最頂端的那些。在底下的那些模組只管實現最小的細節，最頂端的模組關心規模最大的問題。所以，在這個體系結構中越靠上，概念的抽象層次就越高，也越接近問題領域；體系結構中位置越低，概念就越接近細節，與問題領域的關係就越少，而與解決方案領域的關係就越多。

但是，由於上方的模組需要呼叫下方的模組，所以這些上方的模組就依賴於下方的細節。換句話說，與問題領域相關的抽象要依賴於與問題領域無關的細節！這也就是說，當實現細節發生變化時，抽象也會受到影響。而且，如果我們想複用某一個抽象的話，就必須把它依賴的細節都一起拖過去。

而在OOD中，我們希望倒轉這種依賴關係：我們建立的抽象不依賴於任何細節，而細節則高度依賴於上面的抽象。這種依賴關係的倒轉正是OOD和傳統技術之間根本的差異，也正是OOD思想的精華所在。

OOD能給我帶來什麼？

問這個問題的人，腦子裡通常是在想“OOD能解決所有的設計問題嗎？”沒有銀彈。OOD也不是解決一切設計問題、避免軟體危機、捍衛世界和平……的銀彈。OOD只是一種技術。但是，它是一種優秀的技術，它可以很好地解決目前的大多數軟體設計問題——當然，這要求設計者有足夠的能力。

OOD可能會讓你頭疼，因為要學會它、掌握它是很困難的；OOD甚至會讓你失望，因為它也並不成熟、並不完美。OOD也會給你帶來欣喜，它讓你可以專注於設計，而不必操心那些細枝末節；OOD也會使你成為一個更好的設計師，它能提供給你很好的工具，讓你能開發出更堅固、更可維護、更可複用的軟體。

C++是一種“真正的”物件導向程式語言嗎？

最後這個問題和我們今天的主題關係不大，不過這是一個由來已久的問題，而且以後也不一定會有合適的時機說明這個問題，所以今天一起回答了。

很多人都覺得C++缺少“真正的”面嚮物件語言所必須的一些特性，例如垃圾收集（garbage collection）、多分配（multiple-dispatch）之類的。但是，缺少這些特性並不影響開發者們用C++實現物件導向的設計思路。

在我看來，任何語言，只要它直接支援物件導向設計的實現，那它就是“真正的”面嚮物件語言。用這個標準來評價，C++是完全符合的：它直接支援繼承、多型、封裝和抽象，而這些才是物件導向最重要的。而VB和C這樣的語言不能直接支援這些（儘管可以用特殊的技巧來實現），所以不是“真正的”面嚮物件語言。

參考書目

l  [Brooks, 95]  Frederick Brooks, The Mythical Man-Month, Addison-Wesley, 1995.

l  [Li, 02]  李維，《 6/Kylix 2 SOAP/Web Service程式設計篇》，機械工業出版社，2002年。

l  [Martin, 95]  Robert Martin, Designing Object-Oriented C++ Applications Using the Booch Method, Prentice-Hall, 1995.

l  [Stroustrup, 97]  Bjarne Stroustrup, The C++ Programming Language (Special Edition), Addison-Wesley, 1997.

---

我聽見有人說“我可以用C語言實現物件導向”，不過我希望你不會說“我也喜歡這樣做”。很明顯，如果沒有語言特性的支援，物件導向方法將寸步難行。其實結構化設計也是一樣，不過幾乎所有的程式語言都提供了對三種基本流程結構的支援，所以基本不會遇到這個問題。