Dear All: 老實說我對OO的觀念不是很懂,可以介紹一本有關OO觀念介紹或實作的書籍嗎?? 謝謝

物件導向的天空 □林俊杰 前 言 「物件導向」這個名詞越來越熱門，似乎不懂它的人都好像活在上古世界一 般的過時，但知其然者未必知其所以然，物件的定義為何？物件導向的設計哲學 精髓為何？這些問題並非是人人都能答得上來的。 最近學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)。類別也同樣有個定義： 對於具有類似性質、相同的行為、意義及共同關係的物件之描述即為類別。 淺白的說，類別即是具相同性質物件的集合；反之，對於類別而言，物件則 為其「案例」(instance)。 傳統的軟體設計方式是將問題的對象分析之後，採取適當的資料結構來表示 ，並以相對的程序函數演算法來處理資料，兩者看起來似乎獨立而無關。而現在 我們則以「物件」將相關的資料和程序結合成一體，使得兩者的關係看起來更明 白，這是物件導向程式設計最大的特點之一。 資訊隱藏(information hiding)，也就是物件的封裝性(encapsulation)， 可以明白分出物件可以被外界使用的特性及受保護的內部特性。把特性依存取權 限分類可以避免程式的其它部分誤用此物件，而導致不良的副作用。關於封裝性 在第六章有更深入的討論。 Cox 氏認為我們可以藉由建立物件程式庫來達成軟體IC的目標，理由是因為 物件具有重覆使用性(reusability)，而繼承(inheritance)則是達成重覆使用的策 略。叫它繼承可能有些語意不明，不過卻很貼切，以自行車這個類別來說，加裝 一具馬達就成了一部電動機踏車，電動機踏車依然可以前進、剎車，也有車身材 質，只不過多具馬達，因此這個電動機踏車類別便是由腳踏車遺傳而來的。繼承 在視窗的設計上特別有用。由最基本的視窗可以衍生出可捲頁的，可放大縮小的 ......等等各式各樣的視窗。詳細的內容在後面的章節有更深入的介紹。 火車、汽車、機車都可以為人所駕駛。「駕駛」這個動作是個相當抽象的名 詞，火車、汽車、機車的駕駛方法都不一樣，但駕駛一詞涵蓋了實際上具有差異 性的駕駛行為。這種特質稱為「多形性」(polymophism)。 另方面，光知道物於物件的特性實在不足以解決我們的問題，如何將物件引 入軟體設計中呢？如何分析物件？如何遺傳？如何描述一整個系統中物件和物件 間的關係？這些還都是未知的問題。在後文中，筆者將以相當篇幅討論物件方法 論。在這個領域中應首推布奇(Booch)的研究成果，他有效的以圖表分析出物件 的結構及關聯。不過我並不打算多談，因為他的理論較偏重於傳統的設計理論， 對於遺傳等先進的概念顯得較薄弱，筆者將以勞恩森 (Lorensen) 等人所提出的 OMT ( Object Modeling Technique ) 為骨幹。這套理論有一套極完整的發展過 程。OMT是他們用以發展軟體的方法，因此在實作方面的效果相當理想。 物件導向軟體工程有項特點，就是試圖以建立「模型」的方式來分析問題。 OMT法尤甚，它以三種基礎模型來敘述整個軟體的結構、運作模式，它們分別是 ： 瑼咱騧珓(Object Model) 描述物件的結構及物件間的關係 蝪妧A模型(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)，也 就是物件的運作(operation)。再舉前面的例子，自行車類別中關於車身材料等 等靜態的資料就是屬性，而自行車可以做的動作，如前進、煞車等等都屬於屬性 。也就是說，類別中靜態的資料成員就是該類別的屬性，而該類別動態的演算法 就是這個類別的行為或是運作(operation)。那何謂運作，何謂方法(Method)呢 ？兩者有什麼不同呢？前一節曾經提到「駕駛」這個抽象化的工作，「駕駛」在 此便是個operation，而實際的、真正的駕駛則是屬於各別物件的特定方法 (method)。例如說，開轎車的方法和開七四七就不一樣，但一樣都都被稱為是駕 駛，但這不是掛羊頭賣狗肉的勾當！ 請看官大爺注意，在還未實作之前，所有的概念都是抽象化的，因此腦中除 了考慮你的問題外，不必急著去想在電腦上設計的細節，除非你所要解決的問題 本身就與電腦有關。 1.2 物件之間的關係 1.2.1 鏈結(Links) 假定我們現在有二個物件案例(instance)，一位是張老師，一位是王同學。 張老師和王同學這兩個物件的屬性和行為我們暫且不關心。張老師與王同學之間 存在某種關係，由參考圖1.1可以看出張老師「教導」王同學。反過來看，王同 學則「受教」於張老師。這兩個案例間的關係便是鏈結。 1.2.2 關聯(Associations) 在Link鏈結的部分，我們的案例(instance)是張老師和王同學，但老師可能 是趙錢孫李，同學也可能是周吳鄭王。將兩個案例一般化後，我們得到兩個單純 抽象的類別；老師類別(class teacher)及同學類別(class student)。各同學各 老師之間鏈結的集合便稱為關聯(associations)。也就是說，鏈結是真實世界中 物件的關係，而是將鏈結抽象化，一般化後我們便可得到關聯(association)。 讀者在此應先建立一個概念，物件導向的分析規則是由特殊到一般，由實體 到抽象，就像我們先以張老師和王同學為研究樣本，再將他們的關係抽象化。往 後還有更多的例子。 一個老師所施教的對象通常有許多位學生而不只是一位。此時，這個教導的 關係便成一對多(one-to-many)的關係，如圖1.2所示。而若一個學生只向一位老 師求教，教導關係則為1對1(one-to-one)；若一個學生不僅僅只有一位老師，教 導關係就成了多對一了！請讀者試著看懂我們所用的圖形表示法，並且比較其間 的差異。在真實世界中，關係是相當具多樣性的。例如說它可能是個選擇性關係 (optional association)。例如在一夫一妻制國家中，一個男人可以選擇單身（ 無妻）或有唯一的配偶，如圖1.3所示。但中國古時候是行一夫多妻制的，窮漢 子可能一個老婆都沒有；市井小民或許只養得起一口子；天子王侯可能就藏嬌無 數了！這就如圖1.4所示了。圖1.3中的關係是1或無，圖1.4是無或許多。筆者在 此特別聲明我絕對沒別的意思。 關係(association)也可以不只限定於二元關係(binary association)，它 可能是三元性(ternary association)或多元性的。圖1.5 表示老師、學生及教 室的三元關係。 1.2.3 鏈結的屬性(Link attributes) 前面所提到的鏈結都蠻單純的，但真實情況中，鏈結可能有條件或範圍上的 限制。例如在一個多使用者(multi-users)的作業系統(operating system)中， 每個user對檔案的存取都有不同的權限，這點在93期建青筆者拙作「切開MS-DOS 」中有介紹，各位看官可翻閱參考一下。使用者依其層級不同，可以讀寫檔案， 或僅能讀檔，甚至連沾邊的機會都談不上。這麼做的理由是為了保證檔案的安全 所設的規定。此時User這個物件在對於檔案物件的存取關係中，便具有存取權的 屬性。如圖1.6所示。 一個較特殊的鏈接屬性稱為資格(qualificiation)。可將其視為是具有邏輯 性的屬性。例如關卡的通行許可。「通行」只有准許及拒絕的判定，不可能只允 許前腳進，後腳出，身體跨在門中間。因此這種關係是「資格」的判定問題。 1.2.4 集合(aggregation) 「集合」表明了一種物件組成的關係。例如汽車物件是由輪子物件、引擎物 件、齒輪箱物件，車殼物件等等物件所組成的集合體。如果Ａ物件是Ｂ元件的一 部分，Ｂ物件是Ｃ物件的一部分，則Ｂ物件亦會是Ｃ物件的一部分。則Ａ物件是 Ｃ物件的一部分。Ａ物件是Ｂ物件的一部分。則Ｂ物件必非Ａ物件之一部分！ 這個概念在視窗設計上也很有用！你可以利用按鈕物件和視窗物件組合成一 個對話盒物件。集合關係(aggregation)很容易就和遺傳或其他特性搞混了，讀者 宜注意。 1.2.5 遺傳(Inheritance)及歸納關係(Generalization) 我相信只要是對物件導向稍有接觸的朋友都必定對「遺傳」(inheritance) 這名詞不陌生。遺傳和歸納關係提供了程式碼重複使用的可行方案。由生物學的 觀點來看遺傳：子代的特徵都來自於親代。由電腦的觀點來看遺傳：遺傳就是類 似軟體元件共用，並且分享相同的行為以及相似的特性或運作。一個被遺傳的父 代類別 ( parent class ) 被我們稱為「超級類別」(super class)。而子代類 別(child class)被稱為副類別(subclass)。父類別和子類別之間則存在有歸納 關係(Generalization)，而同時也是表示”is-a”或”a-kind-of”的關係，這 代表什麼呢？子類別的案例(instance)同時也必須是父類別的案例。這項特性十 分的合理，假定子類別被修改的和父類別不同，悲劇將無可避免的產生：適用於 父類別的運作(operation)無法正確的適用於子類別上，而設計者在不知情的狀 況下，軟體可能會當掉或失誤。但子類別並非不能修改。你可以修改(refine)及 增加(append)一個子類別的屬性(attribute)及運作(operation)之內部方法 ( method ) ，請讀者回憶前面章節曾說明過運作和方法的差異。運作(operation) 是一個動作的「簽名」(signature)，也就是某一動作的名稱。但筆者在此所說 的修改，是屬於「機能性」的修改，意謂為了適應新物件的運作方式，而必需修 改其內部的方法(method)，以符合新的要求，但該方法最後所要達成的目的應該 和舊方法是一致的，非重新定義。例如我們把”＋”定義為運算上的加法，而你 卻要定義為減法，這不是挺危險的嗎？不幸地，目前的程式語言並不會主動地警 告設計者這個潛在的危險，而成為一個軟體陷井。 剛才我們曾討論了一個重點：為了適應新物件的新特性，而必需修改其內部 的方法，但運作的簽名(signature)卻必需維持相同，這種特稱性便為「凌越」 (overriding)，但和C 中的「多重載入」(overloading)並不相同，請讀者自行 比較。 在此舉一個範例。在一個幾何繪圖的程式中，我們嘗試提供點、線、弧線、 多邊形、圓形的繪圖元件。在此範例中，筆者將以物件分析(OOA)中關於物件模 型的方法來分析這個例子。 我們先試著描述這個繪圖系統的各種圖形元件（先分析案例）。因為用文字 說明佔去篇幅繁浩，故把各物作類別的特性列於圖中。決定各類別後，得視情況 將類別多餘的，無效的屬性或運作剔除，並且將一些可以做成物件的特徵獨立成 為物件（不過在範例中似乎沒有）。下一步是鑑別物件與物件的關係(link)，單 就這些物件來看也缺乏關聯。接下來，觀察這些物件是否用了一些共同的特徵（ 屬性及行為），將共用的特徵萃取出來，形成父類別。在範例中，我們可以先將 物件分成三類，分別是零維、一維及二維圖形(用generalization)，而且一維及 二維圖形可以按比例(scale)伸縮，但三維圖形中間空白部分則可以填色(fill) 還可以把顏色、位置、移動．．．．等等特徵歸納成一個最終的父類別，也就是 圖形(figure)類別。如此我們又得到一張新的參考圖1.7。同時，在此也可以考 慮引用舊的物件。 在圖中，我們發現物件顯示(display)的功能被凌越(overriding)了！為什 麼呢？因為畫法不同啊！但圖形(figure)那個類別要幹啥呢？一點用也沒有！但 他可以表示各subclass的共同特性。任何類別只要有一個運作是抽象的 (abstract)，這個類別就是一個抽象類別(abstract class)。抽象類別不能產生 案例(instance)，但卻可供為遺傳的父類別。相對於抽象類別的是實體類別，實 體類別可以衍生子代，也可以產生案例(instance)。 另一個爭議是應該遺傳幾代。遺傳太多代可能會使子代不好懂。太少嘛，不 太合乎經濟效益，二、三層很好，六、七層勉強接受、十幾層恐怕令人咋舌了。 為什麼呢？是這樣的，理論上類別應該可以被無窮的遺傳，產生新的類別，但是 常常發生在遺傳數代後的子類別的特性竟然「變質」了！父代類別的舊屬性或是 舊運作變得囉唆多餘了，如果你繼續引用遺傳，那可能會變得沒有效率，因此， 筆者認為物件重複遺傳的次數應該會有一個自然上限，但這個上限是幾層呢？這 就和你所設計的物件好壞有關了。 1.2.6 多重繼承(Multiple Inheritance) 前面所提到的都是單源繼承(single inheritance)，十分單純，相較之下， 多重繼承允許一個物件同時繼承許多不同物件的特性，這種方式更接近人類思考 的方法，不過相對也產生不少問題。所謂多重繼承即是一個子物件可同時繼承許 多父類別，通常我們叫這種子類別為「聯合類別」(join class)。 多重繼承最常引發的麻煩便是「模稜兩可」(ambiguity) 的紛爭。這肇因於 父類別中的屬性或運作可能具有類似的簽名。這種情況無法以程式語言的特性避 免（雖然某些程式語言可以設定繼承的優先順序），程式設計師應該要盡力避免 模稜兩可的問題。另外值得注意的一點是某些較舊的物件導向程式語言(OOPL)並 不具備多重繼承的特性，例如：Smalltalk-80，C 1.2，Objective-C。 1.3 集合與其它關係的比較 物件與物件之間的關係是極令人感興趣的，一個程式不太可能僅由一些簡單 的物件架構而成。前面筆者曾說過集合(aggregation)很容易和其他種類的關係 搞混，在這節中，我們將討論它們有啥差異。讀者在往下看之前，不妨自己先比 較一下，看看自己是否也搞混了。 1.3.1 集合和關係(association)的比較 集合是關係(association)一種特例，但集合關係卻特別指出某個特定物件 是由那些物件組成的。就好比一部機器與組成它的螺絲釘之間的關係。主要的判 定方式是：如果一個物件是另一個物件的組成元素，那麼便存在「集合」的關係 了。 1.3.2 集合和遺傳(Inheritance)的比較 集合和遺傳並不一樣。遺傳關係通常被稱為”is-a”或”is-kind-of”（是 一個，是一種），理由前面已經講過了，而集合則被叫做”a-part-of”（一部 分）。 不過，有時我們最好選擇集合關係來替代遺傳的運用。先舉一例。串列結構 (list)是資料結構中一種儲存資料的基本方法，而堆疊(stack)是一種 FILO ( first in ，last out ) 先進後出的結構，關於這方面請讀者自行參考與資料結 構有關的書籍。串列有些基本的運作方法，例如說：增加節點，刪除節點等等。 現在我們要實作堆疊，而堆疊有自己惟一的存取方法也就是它的運作──推入 (push)和彈出(pop)。我們可以採取兩套策略來獲得「堆疊」類別。第一：由串 列遺傳出新的「堆疊」類別，但注意！那些刪除節點之類的運作(operation)也 會被遺傳下來，然而對堆疊來說，不但不需要這些多餘的運作，也不能要，因為 可能意外地刪除節點。因此建議採第二種策略：把串列和堆疊以集合 (aggregation)連起來，就是說把串列變成堆疊的一部分。如圖1.8所示。 關於物件模型(object model)的部分就介紹到此，由於物件模型是最基本而 重要的一部分，讀者宜多留心。 第二章 動態模型 (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 ) 來改變狀態。而這活動可能包括一連串的運作 ( operation ) 。活動 ( activity ) 在圖中的表示方法是在節點中寫個 do:activity name。讀者或許感到筆者一直在強調狀態圖(state diagram)的畫 法。因為構圖表示一個程式十分的重要。前一章物件模型有圖，這章狀態模型也 有圖，下一章功能模型還有ＤＦＤ圖。由此可知圖表的重要性！讀者應該好好的 揣摩圖形的畫法。 第三章 功能模型(Functional Model) 功能模型 ( Functional Model )是OMT 三種基本模型中延用「傳統」的一 部分。功能模型用以描述系統中資料的流程，資料被哪些單元接受處理經由哪些 過程，但卻不深究資料真正是怎麼被計算的。功能模型有效的運用在編譯器 ( compilers ) 之類純粹處理資料的工作，而這些工作所處理的資料不易於被設計 成物件。不過在傳統的設計領域中，除去物件模型，程式一樣可以寫，只不過在 這裡以物件分析為首要觀點，功能模組只得屈身。與其它兩種模型並列了。 3.1 ＤＦＤ資料流程圖 資料流程圖的繪製是功能模型表示方法的核心。ＤＦＤ圖的畫法較前兩章圖 形的畫法都來得簡單，以下就各圖形元件來介紹。 3.1.1 處理單元(process) 我們以一個橢圓形的節點來表示一個「處理」。「處理」(process)用以接 受輸入資料，經過一特定工作方法，將輸入的資料轉換計算後輸出。 3.1.2 資料流(Data Flow) 資料流表示出處理與處理之間所傳遞的資料，在此我們以箭頭符號連接。在 某些例子中，一道資料流（我的意思是僅以一個箭頭符號來表示一道資料流）可 能包含許多資料，而我們或許需要分解其中各別的資料流，此時可以將它分流成 更細的資料流，流入目的「處理」單元。 3.1.3 控制流(control flow) 資料流(Data flow)只是單純的傳遞資料，而不傳送控制訊息。然而某些處 理(process)會需要控制旗標來決定它資料處理的方式，解決的方式並不是經由 資料流傳一個值給處理,在此我們我們另以控制流來解決這個問題。控制的性質 是布林(boolean)代數值，只有真偽兩種情況。基本上控制流應該屬於動態模型 (dynamic model)中的”事件”，但因為和資料處理有密不可分的關係，於是便 被包括進來了。控制流的畫法是以點虛線箭頭表示事件訊息。 3.1.4 資料儲存(data storage)單元 資料儲存單元被視為DFD圖中一個專門用以儲存資料的被動物件。資料儲存 單元的畫法是以二槓橫線表示它。 3.1.5 行事者(Actor) Actor被用來標示資料流的端點，可能是起點，也可能是終點。畫法是以小 三角形來表示。Actor和資料儲存單元有幾分類似。但資料儲存單元是被動的， 而不會執行任何動作，但Actor卻依資料的指示作一些動作，例如產生資料或終 結資料的處理，因此有時也被稱為「終結者」(terminator)。 3.1.6 外界個體 我們用一個矩形來代表外界個體。外界個體是什麼意思呢？因為在ＤＦＤ圖 中總會有資料是由外界輸入進來，也會有資料傳送給外界。因此以外界個體來表 示系統輸入的起點及輸出終點。 3.2 物件、動態模型與功能模型的關係 功能模型描述了一個軟體模型真實地去作了哪些事，ＤＦＤ圖中的「處理」 (Process)單元可以對映到物件模型中的運作(operation)，而資料流則是物件內 的屬性。控制流(control flow)前面也說過是來自於動態模型。整體的來說，三 種模型並不是獨立存在的，而是互補的，只是說它們各自以不同的角度來分析軟 體。功能模型中資料的流程及處理的流程圖並不能表示出處理執行的順序，這點 必需靠動態模型來補足（還記得原因嗎？）。而處理與處理間的流程關係及對於 物件運作(operation)的主客關係。這裡主客關係的意思是：運作(operation)之 間的層次關係，主模組將它的任務切割交由底下的子模組處理。物件模型內的屬 性，也就是狀態的改變，以及運作是如何被引發，怎麼個執行法，都由動態模型 來表達。因此都於所有的軟體來說，三種模型都是基本而且必要的，只不過是重 要程度不同而已。稍後我們所討論的物件發展流程也是照著這三種模型來發展。 第四章 分析 (Analysis) 4.1 OMT的設計流程 OMT方法其實就是一種軟體工程發展法。在此體系中我們採取下列步驟來設 計軟體： 璊尷R(analysis) 分析工作由了解問題定義開始，逐次建立物件、動態、及功能模型來描述軟 體定義域(software domain)，這件工作和真實世界有極大的關聯。 蝔t統設計(System Design) 以物件模型(Object Model)為基礎，開始建立系統的架構，定義動態模型的 劇本，將分析真實世界的結果轉換成電腦世界中型態。 隤咱馧]計(Object Design) 如果說系統設計是承先啟後的的工作，那麼物件設計就是集其大成了。在本 步驟中，三種模型被我們仔細的修改，細部化，具體化，以至於最佳化，將 模型轉換成實際可行的方案，然後進行模組化，最後將結果交給下一步處理 。 暽磣@(implementation) 實作就是將前面所得的結果轉成對映的程式碼。往後在此章節中，筆者將和 大家討論C 的應用。 4.2 分析 這部份的內容在前三章的內容及概念己經被打散進入各模型的介紹中了。我 們現在的工作就是把他們整合起來，並加強一些重點。 分析工作就是要了解問題的定義，因此第一步，整理關於軟體的描述，弄清 楚問題的細節，力求使定義明確而易瞭解，也就是說要由問題陳述(problem statement)來分析軟體的結構。這工作的基本精神和傳統的設計方式是殊無二致 的。筆者曾在前期的拙作中解釋得很明白了。 物件模型的建構：首先把一個物件的結構包括屬性和運作行為列舉出來，找 出物件與物件間的關係。並且要將物件中和問題無關的屬性及運作刪除，同時也 要去除和問題的屬性及運作刪除，同時也要去除和問題無關的關係及鍵結。適當 的引用舊物件，或將同類的物件抽象化，取出共同的父類別來....。有一點需要 留心，最好要有說明文件來記錄物件的性質和運作的目的。相關的內容在第一章 中都說過了，請讀者自行參考。 動態模型表達出物件中事件運作的順序和狀態的改變。首先，你該準備一個 劇本，劇本的來源或許是積數十年的觀案所累積的規則。劇本的內容或許不是鉅 細靡遺，也可能和「連噓劇」一樣無聊，但它卻很重要。然後要找出那些是「事 件」，事件包括信號，輸入，中斷等等。同時要留心每個伴隨事件而生的動作 (action)，及其副作用。然後以劇本為根據作事件追蹤(event trace)，測試事 件發生的先後順序及各事件的目標物件(target object)。 使用者介面 ( User's interface ) 也該在此時期建立。使面者介面的設計 是最難估量的，因為你很難決定怎樣的介面才是最好用 ( easy use ) 和最友善 ( user friendly ) 的，除非到真正設計完成後才能知道效果如何。然而，我們 不得不承認軟體是由程式邏輯的部份和使用者介面合起來的。尤其在今天，軟體 的好壞通常經由使用者介面判定。使用者介面的設計在目前而言並沒有一個很統 一的型式，但將來也很難有一致公認的標準。 關於分析功能模型 ( Functional model ) 方面，主要的工作就是建構ＤＦ Ｄ圖。將資料的流向和處理程序標示出來，就如同前一章所講的一樣，然後本著 「逐步細緻化」的原則，將抽象的處理單元，再細分出它內部的ＤＦＤ圖，一真 重覆這個步驟，直到它們的結構基本到不能再基本為止。 第五章 系統設計(System Design) 系統設計是軟體設計週期中承先啟後的一環。在本階段中有一些首要的目標 ，包含模組化、資源分配、系統結構規劃等等工作。 5.1 模組化 再一次要強調「逐步細緻化」的概念。概念上是將一個大系統切成小系統， 小系統再分成小小系統.....如此遞迴式的切分，可以分析出基本單位、指令碼 ，所以一軟體可能是由幾個主系統，而主系統又由若干個小系統所組成的。我們 試著歸納主系統及子系統間的關係，有層疊(layer)及分割(partition)。 5.1.1 層疊(Layer) 具有層疊關係的從屬模組，其現象是；子模組提供父模組所需的功能，子模 組並不需知道父模組在做什麼，更不會呼叫上層模組。因此，層疊的構成是「垂 直」的相繫。層疊式的關係可以降低機器相依性(machine dependence),因為只 有最底層模組才需「實體化」，中層以上的模組所作的工作都可以是抽象的。因 此為了要適應新的環境，只要抽換底層的模組就可以了。 5.1.2 分割(partition) 分割表示說，模組和模組的連繫是水平方向的。模組間可以相互的呼叫。分 割及層疊結構通常都共存在系統中間可以相互的呼叫。分割及層疊結構通常都共 存在系統中，也沒有孰好孰壞的問題，依系統所需才重要。 5.2 管理資源(resource) 磁碟、螢幕顯示、記憶體、鍵盤、印表機等都是系統資源。管理系統資料的 工作大半都有作業系統把關。不過應用程式也不應任意讓程式內的次系統隨意使 用公共資源。最好的作法是這樣：設計對等於資源的把關者物件，使該物件代表 該資源，由此物件統籌此資源的管理。例如說你可以把某個檔案定義成一個物件 ，定義一些運作.....。當然可能會對存取速度或效率有點影響，但那也是極少 的一點而己，但卻可以用一致的方式來管理資源。 第六章 物件設計(Object Design) 物件設計(Object Design)的工作是規劃工作的最後一環，在這個部份裡， 我們得把模型具體化，最佳化，才能實作。 6.1 演算法(Algorithms)設計 演算法的重要性是無可比擬的。一個好的演算法不但快，而且有效率。請看 這個方程式 f(x)=10*x^250-20*X^249 1求 f(2)=? 嗯，很簡單，把2代進去算， 然後一定會發生悲劇，因為250次方實在太大了，沒法算。可是寫成f(x) = (10x-20)*x^249 1 不就很好算了嗎？這是一個數學演算法的例子。如何去選擇 一個適當的演算法呢？嚴格說來這點將牽涉到演算法分析，需要引用大量的數學 估算，恐怕得寫上一本很厚的書。不過就軟體工程的觀點來看就比較簡單而直觀 了。請各位把握一些要點：選擇那些公認而且沒有爭論的演算法，它們通常是有 效的。但如果你自己設計演算法，將一般性列入考慮。如果演算法不是要被用在 關鍵瓶頸上的，最好是易懂易改的。 為了實作演算法，也同時得選擇合適的資料結構。既然有靜態的資料結構和 動態的演算法，我們可以試著做一些內部類別(internal class)來應付實作演算 法。現在大部份的物件導向程式語言都附有資料結構的物件，可以減去重新設計 演算法的麻煩，真是設計師的福音。 6.2 關聯(association)的設計 我們好像很久都沒看到這個偉大的名詞了。筆者曾提及關聯的運用是很重要 的，但怎麼實作關聯呢？我們試著以關聯用途的方向來分析。 6.2.1 單向關聯(One Way Association) 好幾章前筆者曾以老師及同學類別的交互關係來說明關聯。如果單就「教導 」這關聯來看，純粹是單向性的由老師到學生，而沒有學生「教導」老師。單向 關聯的實作通常以指標達成。如果關聯是一對一(one-to-one)的，則用一個指標 就可以解決，但如果是一對多(one-to-mamy)，則可能要用一組指標，或一個指 標的表格。但如果這關係是有條件限制，則一定要用一個帶有權限值 (qualificiation)的表格來連接了。 6.2.2 雙向關聯 (Two-way association) 在一些情況下，雙向關聯是有必要的。如果去的方向使用率大於反向的使用 率，那麼和單向關聯一樣，用一個指標聯起來就足夠了，在需要用反向關係時， 以搜尋的方法來找到正向指標的來源物件。如果來去雙向使用頻率都差不多，那 麼便用雙指標。在複雜的情況中，例如具有條件的關係或是多對多的關聯之類的 運用便有須要將關聯做成一個物件。基本上，這物件也是一個表格。關於這些類 型的表格，可考慮以雜湊表(hash table)來實作。 6.2.3 關聯的最佳化(Optimization) 我們「物件模型」中所建的物件及其關聯可能是很完整而週密，而且符合現 實的。不過它可能太繁複了。為了傳送一個事件，可能要穿過數個物件，透過數 個關係(association)傳遞。就好像從台北到高雄，走三號省道，得經過近百個 城鎮和數不清的支線才能到達目的地，但如果經過高速公路，就可以直達高雄。 同樣的，在資料傳送頻率高的物件間，即使彼此沒有直接關聯，也可以考慮特別 建立一個關係(association)來達成最佳化資料傳送路徑的目的，以去除傳輸過程 所不需要的冗長步驟。 6.3 遺傳(Inheritance)的運用 物件導向的特點就是它具有遺傳性，我們希望軟體中的物件能夠儘可能地重 覆使用，繼承舊物件，以大量縮減軟體設計的時間及增高可信度。 物件中的一些運作(operation)可能和舊的物件或他同系統中類似的物件中 的運作有相近的功能，但其參數個數卻少了一些。就因為這樣，可能會導致無法 遺傳舊物件，這實在的很可惜。不過，何不替這種運作「補足」多餘的參數呢？ 這真是一個好主意。藉由增加多餘的參數，它們的簽名和功能就可完全一致了！ 例如說在單色繪圖系統上畫點，只需要座標的資料即可，但在彩色系統上卻得要 有顏色(color)的參數，如何達成共用呢？只好在單色畫點的函數中多加一個不 需要、可忽略的顏色參數。讓兩個原來並不相同的運作(operation)，變成簽名 (signature)相同，但內部方法(method)不同的同一個運作。 除了遺傳舊物件以外，新建的類別也可以想法子做「遺傳」。因為相類似的 類別都具有共同的運作及屬性。考慮將這些共同的運作和屬性抽出來成為一個共 同的超級類別。但基於各子類別具有差異性，則某些運作可能是抽象的，於是乎 這個父類別就成了抽象類別了。 這樣作有不少好處。第一：修改其共同的父類別就可以影響到所有的子物件 。第二：可以產生不同的子類別來適應不同的環境。對於前者，筆者認為很淺顯 ，不需多討論，讀者應該可以了解；筆者要歌頌一下第二點。假如你的軟體公司 出售同一套軟體給許多有不同需求的客戶，你毋需大幅增刪你的程式，只要遺傳 新的子類別即可。其次，以一個繪圖系統的繪圖類別而言，為了適應不同的顯示 系統，可以遺傳適應不同機器的類別，在真正上機執行時，再依真實情況引用適 當的類別就可以了。 6.4 資訊隱藏(lnformation Hiding) 在前面章節中，幾乎沒提到資訊隱藏(lnformation Hiding),也就是物件的 封裝性(encapsulation)。封裝性和資料保全(security)不能混為一談，後者指 的是系統資料的保密和安全的可靠性，前者則具有軟體工程上的意義。資訊隱藏 的目的有二，第一：使運作(operation)有限度的存取資料成員，降低其引發的 副作用。也就是說，我們不希望運作會牽一髮而動全身，因此在修改運作的方法 (method)時，可預期的降低物件結構的影響。第二：迫使物件必須建立一個統一 的介面(interface)。透過介面來提取或改變物件屬性，可以有效地遏止類別遭 到意外的破壞。更重要的是，類別介面可以提高類別的抽象化程度，一個愈抽象 的類別對我們愈有利。要怎麼去決定類別中哪些屬性和行為該被隱藏呢？說實話 ，筆者也考慮了很久。一個常見的看法是這樣的：僅將類別的界面顯露出來，而 將其它的元件都隱藏起來。而這又引發了一個問題：我們如何去設計一個好的介 面？筆者心目中好的介面是高度抽象的，而且與內部結構不相涉，能夠考慮到遺 傳後的子類別仍可適用父類別的介面，並且不需要任何增刪修改，但同時也必須 能周延地控制物件的動作。 6.5 類別模組化 傳統的軟體設計很重視模組化，物件導向軟體工程同樣也十分重視模組化， 模組和類別的意義並不相同。筆者認為模組的界定屬於「功能模型」的範疇中， 也就是說將有主客關係或是類似的運作模組化。但如何形成模組呢？模組間又存 在什麼關係呢？我們依舊以「緊密性」來判定模組內成員的關係，而以「關聯性 」來討論模組與模組之間的交互作用。這兩個性質一樣的可以被引用到類別的分 析。模組內若是緊密性低，可能意味著這模組還可以再被切分成更小的子模組。 同樣的，類別內若是緊密度低，那麼這個類別或許也是大而籠統的類別。模組之 間若關聯性過高，應該考慮模組的分割分式是否妥當。同樣的道理引用到類別的 分析上亦是如此。關於模組的緊密性及關聯性的詳細內容，請參考上期建青。 第七章 實作、語言 7.1 物件導向程式語言(Object Oriented Programming Language) 不可否認的，物件導向設計(OOD)和物件導向程式語言的相依程度極高，物 件導向設計的概念在七○年代就出現了，但卻是在八○年代物件導向程式語言發 展成熟之後才大放異彩。傳統的程式語言並非不能應用物件導向方法，只是很難 罷了，例如遺傳 (inheritance) 就很難實作，因此得依賴物件導向專用的程式 語言。但物件導向程式語言並非一夕所成的。從程式語言的發展歷史中，可以看 出一條脈絡來。如果按照一般對語言的分類方式，則有第一代到第四代之不同。 但筆者在此採取資料型態的觀點來看程式語言的演進，歸納出一些結果。上古的 程式語言，如組合語言，沒有今日整數、浮點數的資料表示法；中古的程式語言 如 FORTRAN、BASIC 等有基本的資料型態，如整數、字串型態等等；近代的程式 語言如Ｃ或Pascal，則具備有「集合」式的資料表示法，而新一代的程式語言如 Smalltalk 及C 則具有類別封裝的表示方式。 一個理想的物件導向程式語言(OOPL)能夠確實的將問題的定義域(Domain)映射 到程式中。換句話說，在前面數章所描述的各種物件特性都應該被包含進OOPL。 很不幸地，各種語言都不能很完備地包含那些特性。例如說：多重繼承 (multiple inheritance)並不存在於較舊的OOPL中，例如C 1.2等。而對於多重 繼承(multiple inheritance)解決模稜兩可 (ambiguity) 的方法也不盡相同。 此外，我們希望程式語言能夠提供一套標準的類別程式庫(Class library)，就 像Smalltalk一樣，設計師可以自由運用上百個已定義的物件。而C ，頂多以 iostream的I/O物件充數。各家物件導向程式語言對於物件導向的詮釋都有所不 同，導致於它們在物件導向理論中的細節看法都不一樣，這點讀者不可不注意。 此外目前OOPL產生新類別的方法都是在程式寫作時在程式碼中載明遺傳方式 。將來則可能會出現在執行時期(run-time)可產生物件的程式語言。屆時相當多 的問題也可一併解決。 第八章 關於C 雖然Smalltalk的歷史、名氣可能都來得比C 大，但C 的適用性較強。對 於C 的介紹真是多如過江之鯽，諸有興趣的讀者自行參考，在本章中將探討C 在物件設計中的應用。 8.1 「類別」Vs「類別」 不要以為這節的名稱搞錯了。C 中的類別與物件模型 ( object model )中 的類別有啥差異呢？就抽象化的層次而言，兩者的意義是相等的。就實際情況來 說，C 的類別的成員存取屬性可分為公共(public)、保護(protected)及私有 (private)三區。在不討論遺傳的情形下，保護(protected)及私有(private)屬 均性是類別中被隱藏的部分。而只用於遺傳時，public及protected方能遺傳給 子類別。為什麼要這樣定義呢？這是個很有趣的問題。根據筆者的研究， private成員事實上一樣也會被遺傳給子類別，但不能被子類別的成員存取。這 屬於一種隱性的遺傳(implicit inheritance ) ，但從另一個角度來看，private 成員可以被當成該類別暫時性成員，可能是為了要完成某個運作(operation)內 的方法(method)，而需要的內部類別(internal class)或輔助的子模組。這些成 員的遺傳不具意義，也就成了隱性遺傳。 8.2 凌越(overriding)與多重載入(overloading)

OOP經典文章附件 （由axsoft大大提供）    http://delphi.ktop.com.tw/topic.php?TOPIC_ID=21757     ---------------- 局局棋盤步步新， 變化無常平常待。 人生相處平常心， 無憂無慮心事成。 ----------------

物件導向雜誌免費下載 http://home.pchome.com.tw/art/object777/index.html 免費資源 http://delphi.ktop.com.tw/topic.php?TOPIC_ID=24830 *************************************************************************** 哈哈&兵燹 最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好

------
**********************************************************
哈哈&兵燹
最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好

Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知
K.表Knowlege 知識,就是本站的標語:Open our mind