物件導向設計（object-oriented design，ood）方法是oo方法中乙個中間過渡環節。其主要作用是對ooa分析的結果作進一步的規範化整理，以便能夠被oop直接接受。
物件導向設計（ood）是一種軟體設計方法，是一種工程化規範。這是毫無疑問的。按照bjarne stroustrup的說法，物件導向的程式設計正規化（paradigm）是[stroustrup, 97]：
l 決定你要的類；
l 給每個類提供完整的一組操作；
l 明確地使用繼承來表現共同點。
由這個定義，我們可以看出：ood就是「根據需求決定所需的類、類的操作以及類之間關聯的過程」。
ood的目標是管理程式內部各部分的相互依賴。為了達到這個目標，ood要求將程式分成塊，每個塊的規模應該小到可以管理的程度，然後分別將各個塊隱藏在介面（inte***ce）的後面，讓它們只通過介面相互交流。比如說，如果用ood的方法來設計乙個伺服器-客戶端（client-server）應用，那麼伺服器和客戶端之間不應該有直接的依賴，而是應該讓伺服器的介面和客戶端的介面相互依賴。
這種依賴關係的轉換使得系統的各部分具有了可復用性。還是拿上面那個例子來說，客戶端就不必依賴於特定的伺服器，所以就可以復用到其他的環境下。如果要復用某乙個程式塊，只要實現必須的介面就行了。
ood是一種解決軟體問題的設計正規化（paradigm），一種抽象的正規化。使用ood這種設計正規化，我們可以用物件（object） 來表現問題領域（problem domain）的實體，每個物件都有相應的狀態和行為。我們剛才說到：ood是一種抽象的正規化。抽象可以分成很多層次，從非常概括的到非常特殊的都有，而 物件可能處於任何乙個抽象層次上。另外，彼此不同但又互有關聯的物件可以共同構成抽象：只要這些物件之間有相似性，就可以把它們當成同一類的物件來處理。
一、ood背景知識
計算機硬體技術卻在飛速發展。從幾十年前神秘的龐然大物，到現在隨身攜帶的移動晶元；從每秒數千次運算到每秒上百億次運算。當軟體開發者們還在尋找能讓軟體開發生產力提高乙個數量級的「銀彈」[brooks, 95]時，硬體開發的生產力早已提公升了百倍千倍。
硬體工程師們能夠如此高效，是因為他們都很懶惰。他們永遠恪守「不要去重新發明輪子」的古訓。grady booch把這些黑箱稱為類屬（class category），現在我們則通常把它們稱為「元件（component）」。
軟體的復用最初是從函式庫和類庫開始的，這兩種復用形式實際上都是白箱復用。到90年代，開始有人開發並**真正的黑箱軟體模組：框架（framework） 和控制項（control）。框架和控制項往往還受平台和語言的限制，現在軟體技術的新潮流是用soap作為傳輸介質的web service，它可以使軟體模組脫離平台和語言的束縛，實現更高程度的復用。但是想一想，其實web service也是物件導向，只不過是把類與類之間的關聯用xml來描述而已[li, 02]。
在過去的十多年裡，物件導向技術對軟體行業起到了極大的推動作用。在可以**的將來，它仍將是軟體設計的主要技術——至少我看不到有什麼技術可以取代它的。
二、ood到底從哪兒來？
有很多人都認為：ood是對結構化設計（structured design，sd）的擴充套件，其實這是不對的。ood的軟體設計觀念和sd完全不同。sd注重的是資料結構和處理資料結構的過程。而在ood中，過程和數 據結構都被物件隱藏起來，兩者幾乎是互不相關的。不過，追根溯源，ood和sd有著非常深的淵源。
2023年前後，ood和sd的概念幾乎同時誕生，它們分別以不同的方式來表現資料結構和演算法。當時，圍繞著這兩個概念，很多科學家寫了大量的**。其 中，由dijkstra和hoare兩人所寫的一些**講到了「恰當的程式控制結構」這個話題，聲稱goto語句是有害的，應該用順序、迴圈、分支這三種 控制結構來構成整個程式流程。這些概念發展構成了結構化程式設計方法；而由ole-johan dahl所寫的另一些**則主要討論程式語言中的單位劃分，其中的一種程式單位就是類，它已經擁有了物件導向程式設計的主要特徵。
這兩種概念立刻就分道揚鑣了。在結構化這邊的歷史大家都很熟悉：nato會議採納了dijkstra的思想，整個軟體產業都同意goto語句的確是有害的，結構化方法、瀑布模型從70年代開始大行其道。同時，無數的科學家和軟體工程師也幫助結構化方法不斷發展完善，其中有很多今天足以使我們振聾發聵的名字，例如constantine、yourdon、demarco和dijkstra。有很長一段時間，整個世界都相信：結構化方法就是拯救軟體工業的「銀彈」。當然，時間最後證明了一切。
而此時，物件導向則在研究和教育領域緩慢發展。結構化程式設計幾乎可以應用於任何程式語言之上，而物件導向程式設計則需要語言的支援[1]，這也妨礙了面 向物件技術的發展。實際上，在60年代後期，支援物件導向特性的語言只有simula-67這一種。到70年代，施樂帕洛阿爾托研究中心（parc）的 alan key等人又發明了另一種基於物件導向方法的語言，那就是大名鼎鼎的**alltalk。但是，直到80年代中期，**alltalk和另外幾種物件導向語言仍然只停留在實驗室裡。
到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也會使你成為乙個更好的設計師，它能提供給你很好的工具，讓你能開發出更堅固、更可維護、更可復用的軟體。
物件導向設計
1 物件導向的三要素 1.1 封裝 encapsulation a 封裝 合理的隱藏資料的隱藏 隱藏在方法背後 實現的隱藏 隱藏在介面背後 變化的隱藏 隱藏在抽象背後 b 封裝能夠提高物件的復用性 減低物件的耦合度c 良好的封裝 物件的高內聚 1.2 繼承 inheritance a 基於差異式程式...
物件導向設計
物件導向的設計把握乙個重要原則 誰擁有資料，誰就對外提供操作這些資料的方法。人在黑板上畫圓 person,blackboard,circle draw 列車司機在剎車 人關門 兩塊石頭磨成一把石刀，石刀可以砍樹，砍成木材，木材可以做椅子。stone石頭 stoneknife石刀 stoneknife...
物件導向設計
物件導向的基本要素 封裝 繼承 多型。封裝的目的是隱藏事務內部的實現細節，以便提高安全性和簡化程式設計。封裝提供了合理的邊界，避免外部呼叫者接觸到內部的細節。我們在日常開發中，因為無意間暴露了細節導致的難纏 bug 太多了，比如在多執行緒環境暴露內部狀態，導致的併發修改問題。從另外乙個角度看，封裝這...