什么是物件导向呀？

libingcumt

台湾的书上经常这么讲，是面向对象的意思吗？

log96

物件導向的天空
                                                              □林俊杰

前    言

　　「物件導向」這個名詞越來越熱門，似乎不懂它的人都好像活在上古世界一
般的過時，但知其然者未必知其所以然，物件的定義為何？物件導向的設計哲學
精髓為何？這些問題並非是人人都能答得上來的。

　　最近學C++的人口也開始上升，恐怕又會帶動另一股流行的風氣。但荒謬的
是大部分C++的教科書所講的內容根本就是Ｃ語言，外加一點物件導向程式設計
(OOP)的皮毛。這樣做真能學好C++嗎？筆者見真正把Ｃ的設計哲學搞懂的人士實
在不多，恐怕真正弄懂C++的更少。如果缺乏物件設計哲學概念的人用C++所寫的
程式恐怕也只是比較特別的Ｃ罷了。

　　其實物件導向是門很有趣的設計哲學，它試圖由人們對問題的看法來解釋軟
體的架構，並力求將問題的定義域映射到分析的模型，再轉成相對的程式碼。目
前使用物件導向技術的軟體如雨後春筍般地蓬勃發展，因此無論你是不是專業的
工程師，都應該對物件有所瞭解。

　　在後文中，將以物件導向軟體工程論為討論的核心，最後觸及C++與物件設
計的關係。如此精采的文章，你若再不猛Ｋ，豈有國法天理人情良心乎！

第 一 章    何謂物件 (OBJECTS)

　　物件的原文是Object，國內也有人把他譯為「個體」，「項目」、「目的」
等等，但為統一起見，在本文中一律統稱物件。而以物件為基礎的軟體設計哲學
，則一律冠以「物件導向」 (Object Oriented，簡寫為OO)的頭銜。故物件導向
程式設計便稱OOP  (Object  Oriented  Programming  ) 物體導向分析(Object
Oriented  analysis, OOA)，物件導向程式語言(Object Oriented Programming
Lagnage,OOPL)如此類推，不一而足。然而，到底物件是什麼呢？電腦學家給它
一個定義：

　　一個抽象體、概念、或是一個有明確界定範圍的事物，並且在我們要解決的
    問題中是有意義的。

　　舉兩個例子：筆者有部腳踏車，這是個物件，閣下手上看的建青也是個物件
。生活中形形色色的事物也都是物件，閣下亦復如此。這點概念大家都可以接受
，但光定義物件沒用，車子依舊在路上跑，和閣下的程式毫不相涉。再進一步去
研究，筆者的自行車是以鋁合金為車骨，輕且不生銹，而且它可以前進，可以剎
車，這也都沒啥奇怪，但經由以上的描述，我們已經定義出筆者的自行車，和它
的特性（鋁合金車架），及它的功能（前進、剎車）。當然這樣可能尚未臻周延
，因為我沒說我的車子有輪子，但我的程式或許不必知道那麼多！假定讀者你也
有部腳踏車，你的腳踏車的車身是塑膠製的，同樣的，您的車也可以前進、剎車
！理所當然，你的車也是個物件！上面提到筆者的及閣下的自行車，但其它的張
三李四也會有自行車，其中有鐵的，也可能有紙糊的！此時我們可定義一個叫「
自行車」的「類別」(class)。類別也同樣有個定義：

　　對於具有類似性質、相同的行為、意義及共同關係的物件之描述即為類別。

　　湴椎恼f，類別即是具相同性質物件的集合；反之，對於類別而言，物件則
為其「案例」(instance)。

　　傳統的軟體設計方式是將問題的對象分析之後，採取適當的資料結構來表示
，並以相對的程序函數演算法來處理資料，兩者看起來似乎獨立而無關。而現在
我們則以「物件」將相關的資料和程序結合成一體，使得兩者的關係看起來更明
白，這是物件導向程式設計最大的特點之一。

　　資訊隱藏(information  hiding)，也就是物件的封裝性(encapsulation)，
可以明白分出物件可以被外界使用的特性及受保護的內部特性。把特性依存取權
限分類可以避免程式的其它部分誤用此物件，而導致不良的副作用。關於封裝性
在第六章有更深入的討論。

　　Cox 氏認為我們可以藉由建立物件程式庫來達成軟體IC的目標，理由是因為
物件具有重覆使用性(reusability)，而繼承(inheritance)則是達成重覆使用的策
略。叫它繼承可能有些語意不明，不過卻很貼切，以自行車這個類別來說，加裝
一具馬達就成了一部電動機踏車，電動機踏車依然可以前進、剎車，也有車身材
質，只不過多具馬達，因此這個電動機踏車類別便是由腳踏車遺傳而來的。繼承
在視窗的設計上特別有用。由最基本的視窗可以衍生出可捲頁的，可放大縮小的
......等等各式各樣的視窗。詳細的內容在後面的章節有更深入的介紹。

　　火車、汽車、機車都可以為人所駕駛。「駕駛」這個動作是個相當抽象的名
詞，火車、汽車、機車的駕駛方法都不一樣，但駕駛一詞涵蓋了實際上具有差異
性的駕駛行為。這種特質稱為「多形性」(polymophism)。

　　另方面，光知道物於物件的特性實在不足以解決我們的問題，如何將物件引
入軟體設計中呢？如何分析物件？如何遺傳？如何描述一整個系統中物件和物件
間的關係？這些還都是未知的問題。在後文中，筆者將以相當篇幅討論物件方法
論。在這個領域中應首推布奇(Booch)的研究成果，他有效的以圖表分析出物件
的結構及關聯。不過我並不打算多談，因為他的理論較偏重於傳統的設計理論，
對於遺傳等先進的概念顯得較薄弱，筆者將以勞恩森 (Lorensen) 等人所提出的
OMT ( Object Modeling Technique ) 為骨幹。這套理論有一套極完整的發展過
程。OMT是他們用以發展軟體的方法，因此在實作方面的效果相當理想。

　　物件導向軟體工程有項特點，就是試圖以建立「模型」的方式來分析問題。
OMT法尤甚，它以三種基礎模型來敘述整個軟體的結構、咦髂Ｊ剑?鼈兎謩e是
：

?物件模型(Object Model)

　　描述物件的結構及物件間的關係

?動態模型(Dynamic Model)

　　系統的狀況時時都有變化，動態模型以事件發生和狀態的改變來描述系統中
    的交互作用。

?功能模型(Functional Model)

　　功能模型是OMT包容傳統軟體設計的一部分。它藉由資料流程圖(Data  Flow
    Diagram，DFD)來描述資料轉換或計算之流程。關於DFD，讀友可參考建青
    94期筆者拙作「軟體設計的思維」一文。

　　OMT的軟體設計步驟是分析(Analysis)、系統設計(System Design)、物件設
計(Object  Design)在來是實作(Implementation)之本質則是以物件觀點建立前
述三種模型，再加以設計、統合、然後映射成為程式碼。

　　藉由物件導向的方式來設計軟體可以有效的提升軟體設計的效率，（雖然在
由舊方法轉入物件導向時可能會有降低的現象）。舉個明顯的例子：Borland 公
司在Quattro推出半年多後推出Quattro Pro，三個月後視窗版就問世了。這麼快的
速度完全是拜物件導向法所賜，也使Borland公司大賺其錢（該公司號稱年成長
率百分之兩百）。以生產dBASE著名的安信達公司在dBASE III推出數年後才推出
dBASE IV 1.0版，而且還是伴隨一堆Bug上市的。最後，在幾個月前Borland終於
併吞了安信達！

1.2　物件模型(Object Model)

　　物件必定具備兩個基本的構要素：屬性(attributes)及行為(behavior)，也
就是物件的咦

log96

第二章　動態模型 (Dynamic Model)

2.1  概說

　　上一章所討論的物件模型，是屬於物件導向中靜態的部分。而這章則要仔細
地探討物件的行為，及物件之間的交互作用。

2.2  事件(events)和狀態(states)

　　概括的說，物件中的屬性及鏈結(link)，都屬於該物件的狀態(state)。而
一物件之狀態則會因事件(events)的影響而改變。在下面的討論中，讀者會發現
我們較偏重於即時(real-time)程式的設計，事實上亦是如此。

　　事件是指發生在某時刻的某事，而且理論上它並不會持續一段時間。例如電
話鈴響就是一種事件。事件通常由一個物件發出，而被另一個物件接受。而且事
件只是單向性的訊息傳遞，而不像函數會帶有傳回值。事件也是一種特殊的類別
，他可以具備有屬性。例如說：撥電話號碼(dial)這個動作也隱含著撥某個號碼
，例如說：撥”5”、撥”1”等等。同理，「錯誤」也可以被設計成事件，而且
伴隨有錯誤代碼。

　　狀態(states)是物件屬性或鏈結的抽象體。狀態是被動的而且只在此事件發
生後才改變，因此我們可視為兩事件發生間的時間為此物件的狀態，也就是說，
某個狀態將會持續一段時間，直到下個事件發生為止。

　　為了表示出一連串的事件及他們發生的順序，我們得編一套事件的「劇本」
(scenario)。這個劇本十分重要，有劇本才能讓模型”活起來”。劇本的產生通
常是以平常可能發生的情況為主體，再加入例外。然而，劇本也有可能不甚詳盡
，但是可以改！

　　劇本準備好了之後，可以作事件追蹤(event  trace)的模擬。事件追蹤可以
明確的看出來誰產生了事件，誰接收了事件，何時產生事件，那個事件先發生…
…等等。接著再作一份事件流程圖(event flow diagram)，顯示哪個物件該產生
那些事件，該接收哪些事件等等。

　　狀態圖(state  diagram)則很清楚的表示了事件的流程及對狀態的影響，以
下將教您如何畫圖。在狀態圖中，用節點(一個橢圓形)表示此物件的狀態
(state)，而箭頭旁則標明了事件名稱，在事件的流程圖上可加以標示「判斷」
布林值以決定事件的流向，在後面有張紅綠燈的狀態圖，在此扼要的加以說明。
這個號誌系統是個長「眼睛」的紅綠燈，藉由偵測在左彎車專用道上是否有車，
來決定是否要讓直行車先行或留一段時間給轉彎車走。你可以看得出來，例如說
南北向要彎紅燈時，會先判斷要不要先亮轉彎燈，如果不要，就直接跳到東西亮
線燈的狀態去。在此，那個判斷值便標明在事件的箭頭上，其餘依此類推。

2.3  動作(Action)與活動(Activity)

　　光在圖上標出事件、狀態及判定值還不太夠，通常伴隨事件之後應該會有一
項對應的動作  ( Action ) ，它在圖中的表示法是在事件敘述後加斜線”/”區
隔。事件的發生只是告知或確認狀態的改變，至於如何轉變狀態則和事件無關，
必須靠內部的活動 ( activity ) 來改變狀態。而這活動可能包括一連串的咦

log96

就是OO的方法

neuIE

LOG96兄说得实在是太复杂了.其实就是"面向对象",在台湾叫物件导向