中科永聯高級技術培訓中心（www.itisedu.com）
面向對象設計（Object-Oriented Design，OOD）方法是OO方法中一個中間過渡環節。其主要作用是對OOA分析的結果作進一步的規範化整理，以便能夠被OOP直接接受。
面向對象設計（OOD）是一種軟體設計方法，是一種工程化規範。這是毫無疑問的。按照Bjarne Stroustrup的說法，面向對象的編程範式（paradigm）是【Stroustrup, 97】：
l 決定你要的類；
l 給每個類提供完整的一組操作；
l 明確地使用繼承來表現共同點。
由這個定義，我們可以看出：OOD就是“根據需求決定所需的類、類的操作以及類之間關聯的過程”。
OOD的目標是管理程式內部各部分的相互依賴。為了達到這個目標，OOD要求將程式分成塊，每個塊的規模應該小到可以管理的程度，然後分別將各個塊隱藏在接口（interface）的後面，讓它們只通過接口相互交流。比如說，如果用OOD的方法來設計一個伺服器-客戶端（client-server）套用，那么伺服器和客戶端之間不應該有直接的依賴，而是應該讓伺服器的接口和客戶端的接口相互依賴。
這種依賴關係的轉換使得系統的各部分具有了可復用性。還是拿上面那個例子來說，客戶端就不必依賴於特定的伺服器，所以就可以復用到其他的環境下。如果要復用某一個程式塊，只要實現必須的接口就行了。
OOD是一種解決軟體問題的設計範式（paradigm），一種抽象的範式。使用OOD這種設計範式，我們可以用對象（object）來表現問題領域（problem domain）的實體，每個對象都有相應的狀態和行為。我們剛才說到：OOD是一種抽象的範式。抽象可以分成很多層次，從非常概括的到非常特殊的都有，而對象可能處於任何一個抽象層次上。另外，彼此不同但又互有關聯的對象可以共同構成抽象：只要這些對象之間有相似性，就可以把它們當成同一類的對象來處理。
一、OOD背景知識
計算機硬體技術卻在飛速發展。從幾十年前神秘的龐然大物，到現在隨身攜帶的移動晶片；從每秒數千次運算到每秒上百億次運算。當軟體開發者們還在尋找能讓軟體開發生產力提高一個數量級的“銀彈”【Brooks, 95】時，硬體開發的生產力早已提升了百倍千倍。
硬體工程師們能夠如此高效，是因為他們都很懶惰。他們永遠恪守“不要去重新發明輪子”的古訓。Grady Booch把這些黑箱稱為類屬（class category），現在我們則通常把它們稱為“組件（component）”。
類屬是由被稱為類（class）的實體組成的，類與類之間通過關聯（relationship）結合在一起。一個類可以把大量的細節隱藏起來，只露出一個簡單的接口，這正好符合人們喜歡抽象的心理。所以，這是一個非常偉大的概念，因為它給我們提供了封裝和復用的基礎，讓我們可以從問題的角度來看問題，而不是從機器的角度來看問題。
軟體的復用最初是從函式館和類庫開始的，這兩種復用形式實際上都是白箱復用。到90年代，開始有人開發並出售真正的黑箱軟體模組：框架（framework）和控制項（control）。框架和控制項往往還受平台和語言的限制，現在軟體技術的新潮流是用SOAP作為傳輸介質的Web Service，它可以使軟體模組脫離平台和語言的束縛，實現更高程度的復用。但是想一想，其實Web Service也是面向對象，只不過是把類與類之間的關聯用XML來描述而已【Li, 02】。
在過去的十多年裡，面向對象技術對軟體行業起到了極大的推動作用。在可以預測的將來，它仍將是軟體設計的主要技術——至少我看不到有什麼技術可以取代它的。
二、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。有很長一段時間，整個世界都相信：結構化方法就是拯救軟體工業的“銀彈”。當然，時間最後證明了一切。
而此時，面向對象則在研究和教育領域緩慢發展。結構化程式設計幾乎可以套用於任何程式語言之上，而面向對象程式設計則需要語言的支持【1】，這也妨礙了面向對象技術的發展。實際上，在60年代後期，支持面向對象特性的語言只有Simula-67這一種。到70年代，施樂帕洛阿爾托研究中心（PARC）的Alan Key等人又發明了另一種基於面向對象方法的語言，那就是大名鼎鼎的Smalltalk。但是，直到80年代中期，Smalltalk和另外幾種面向對象語言仍然只停留在實驗室里。
到90年代，OOD突然就風靡了整個軟體行業，這絕對是軟體開發史上的一次革命。不過，登高才能望遠，新事物總是站在舊事物的基礎之上的。70年代和80年代的設計方法揭示出許多有價值的概念，誰都不能也不敢忽視它們，OOD也一樣。
三、OOD和傳統方法有什麼區別？
還記得結構化設計方法嗎？程式被劃分成許多個模組，這些模組被組織成一個樹型結構。這棵樹的根就是主模組，葉子就是工具模組和最低級的功能模組。同時，這棵樹也表示調用結構：每個模組都調用自己的直接下級模組，並被自己的直接上級模組調用。
那么，哪個模組負責收集應用程式最重要的那些策略？當然是最頂端的那些。在底下的那些模組只管實現最小的細節，最頂端的模組關心規模最大的問題。所以，在這個體系結構中越靠上，概念的抽象層次就越高，也越接近問題領域；體系結構中位置越低，概念就越接近細節，與問題領域的關係就越少，而與解決方案領域的關係就越多。
但是，由於上方的模組需要調用下方的模組，所以這些上方的模組就依賴於下方的細節。換句話說，與問題領域相關的抽象要依賴於與問題領域無關的細節！這也就是說，當實現細節發生變化時，抽象也會受到影響。而且，如果我們想復用某一個抽象的話，就必須把它依賴的細節都一起拖過去。
而在OOD中，我們希望倒轉這種依賴關係：我們創建的抽象不依賴於任何細節，而細節則高度依賴於上面的抽象。這種依賴關係的倒轉正是OOD和傳統技術之間根本的差異，也正是OOD思想的精華所在。
四、OOD步驟
細化重組類
細化和實現類間關係,明確其可見性
增加屬性,指定屬性的類型與可見性
分配職責,定義執行每個職責的方法
對訊息驅動的系統,明確訊息傳遞方式
利用設計模式進行局部設計
畫出詳細的類圖與時序圖
五、OOD設計過程中要展開的主要幾項工作
（一）對象定義規格的求精過程
對於OOA所抽象出來的對象-＆-類以及匯集的分析文檔，OOD需要有一個根據設計要求整理和求精的過程，使之更能符合OOP的需要。這個整理和求精過程主要有兩個方面：一是要根據面向對象的概念
模型整理分析所確定的對象結構、屬性、方法等內容，改正錯誤的內容，刪去不必要和重複的內容等。二是進行分類整理，以便於下一步資料庫設計和程式處理模組設計的需要。整理的方法主要是進行歸
類，對類一＆一對象、屬性、方法和結構、主題進行歸類。
（二）數據模型和資料庫設計
數據模型的設計需要確定類-＆-對象屬性的內容、訊息連線的方式、系統訪問、數據模型的方法等。最後每個對象實例的數據都必須落實到面向對象的庫結構模型中。
（三）最佳化
OOD的最佳化設計過程是從另一個角度對分析結果和處理業務過程的整理歸納，最佳化包括對象和結構的最佳化、抽象、集成。
對象和結構的模組化表示OOD提供了一種範式，這種範式支持對類和結構的模組化。這種模組符合一般模組化所要求的所有特點，如信息隱蔽性好，內部聚合度強和模組之間耦合度弱等。
集成化使得單個構件有機地結合在一起，相互支持。
六、OO方法的特點和面臨的問題
OO方法以對象為基礎，利用特定的軟體工具直接完成從對象客體的描述到軟體結構之間的轉換。這是OO方法最主要的特點和成就。OO方法的套用解決了傳統結構化開發方法中客觀世界描述工具與軟
件結構的不一致性問題，縮短了開發周期，解決了從分析和設計到軟體模組結構之間多次轉換映射的繁雜過程，是一種很有發展前途的系統開發方法。
但是同原型方法一樣,OO方法需要一定的軟體基礎支持才可以套用，另外在大型的MIS開發中如果不經自頂向下的整體劃分，而是一開始就自底向上的採用OO方法開發系統，同樣也會造成系統結構不合理、各部分關係失調等問題。所以OO方法和結構化方法目前仍是兩種在系統開發領域相互依存的、不可替代的方法。
七、OOD能給我帶來什麼？
問這個問題的人，腦子裡通常是在想“OOD能解決所有的設計問題嗎？”沒有銀彈。OOD也不是解決一切設計問題、避免軟體危機、捍衛世界和平……的銀彈。OOD只是一種技術。但是，它是一種優秀的技術，它可以很好地解決目前的大多數軟體設計問題——當然，這要求設計者有足夠的能力。
OOD可能會讓你頭疼，因為要學會它、掌握它是很困難的；OOD甚至會讓你失望，因為它也並不成熟、並不完美。OOD也會給你帶來欣喜，它讓你可以專注於設計，而不必操心那些細枝末節；OOD也會使你成為一個更好的設計師，它能提供給你很好的工具，讓你能開發出更堅固、更可維護、更可復用的軟體。
