注：本文來源于《   在java中，OOA是什麼？OOD是什麼？OOP是什麼？》

在java中，OOA是什麼？OOD是什麼？OOP是什麼？

                             OOA

　　Object-Oriented Analysis：面向對象分析方法

　　是在一個系統的開發過程中進行了系統業務調查以後，按照面向對象的思想來分析問題。OOA與結構化分析有較大的差別。OOA所強調的是在系統調查資料的基礎上，針對OO方法所需要的素材進行的歸類分析和整理，而不是對管理業務現狀和方法的分析。

　　OOA（面向對象的分析）模型由5個層次（主題層、對象類層、結構層、屬性層和服務層）和5個活動（辨別對象類、辨別結構、定義主題、定義屬性和定義服務）組成。在這種方法中定義了兩種對象類之間的結構，一種稱為分類結構，一種稱為組裝結構。分類結構就是所謂的一般與特殊的關系。組裝結構則反映了對象之間的整體與部分的關系。

　　OOA在定義屬性的同時，要識别執行個體連接配接。執行個體連接配接是一個執行個體與另一個執行個體的映射關系。

　　OOA在定義服務的同時要識别消息連接配接。當一個對象需要向另一對象發送消息時，它們之間就存在消息連接配接。

　　OOA 中的5個層次和5個活動繼續貫穿在OOD（畫向對象的設計）過程中。OOD模型由4個部分組成。它們分别是設計問題域部分、設計人機互動部分、設計任務管理部分和設計資料管理部分。

　　一、OOA的主要原則。

　　（1）抽象：從許多事物中舍棄個别的、非本質的特征，抽取共同的、本質性的特征，就叫作抽象。抽象是形成概念的必須手段。

　　抽象原則有兩方面的意義：第一，盡管問題域中的事物是很複雜的，但是分析員并不需要了解和描述它們的一切，隻需要分析研究其中與系統目标有關的事物及其本質性特征。第二，通過舍棄個體事物在細節上的差異，抽取其共同特征而得到一批事物的抽象概念。

　　抽象是面向對象方法中使用最為廣泛的原則。抽象原則包括過程抽象和資料抽象兩個方面。

　　過程抽象是指，任何一個完成确定功能的操作序列，其使用者都可以把它看作一個單一的實體，盡管實際上它可能是由一系列更低級的操作完成的。

　　資料抽象是根據施加于資料之上的操作來定義資料類型，并限定資料的值隻能由這些操作來修改和觀察。資料抽象是OOA的核心原則。它強調把資料（屬性）和操作（服務）結合為一個不可分的系統機關（即對象），對象的外部隻需要知道它做什麼，而不必知道它如何做。

　　（2）封裝就是把對象的屬性和服務結合為一個不可分的系統機關，并盡可能隐蔽對象的内部細節。

　　（3）繼承：特殊類的對象擁有的其一般類的全部屬性與服務，稱作特殊類對一般類的繼承。

　　在OOA中運用繼承原則，就是在每個由一般類和特殊類形成的一般—特殊結構中，把一般類的對象執行個體和所有特殊類的對象執行個體都共同具有的屬性和服務，一次性地在一般類中進行顯式的定義。在特殊類中不再重複地定義一般類中已定義的東西，但是在語義上，特殊類卻自動地、隐含地擁有它的一般類（以及所有更上層的一般類）中定義的全部屬性和服務。繼承原則的好處是：使系統模型比較簡練也比較清晰。

　　（4）分類：就是把具有相同屬性和服務的對象劃分為一類，用類作為這些對象的抽象描述。分類原則實際上是抽象原則運用于對象描述時的一種表現形式。

　　（5）聚合：又稱組裝，其原則是：把一個複雜的事物看成若幹比較簡單的事物的組裝體，進而簡化對複雜事物的描述。

　　（6）關聯：是人類思考問題時經常運用的思想方法：通過一個事物聯想到另外的事物。能使人發生聯想的原因是事物之間确實存在着某些聯系。

　　（7）消息通信：這一原則要求對象之間隻能通過消息進行通信，而不允許在對象之外直接地存取對象内部的屬性。通過消息進行通信是由于封裝原則而引起的。在OOA中要求用消息連接配接表示出對象之間的動态聯系。

　　（8）粒度控制：一般來講，人在面對一個複雜的問題域時，不可能在同一時刻既能縱觀全局，又能洞察秋毫。是以需要控制自己的視野：考慮全局時，注意其大的組成部分，暫時不詳察每一部分的具體的細節；考慮某部分的細節時則暫時撇開其餘的部分。這就是粒度控制原則。

　　（9）行為分析：現實世界中事物的行為是複雜的。由大量的事物所構成的問題域中各種行為往往互相依賴、互相交織。

　　二、面向對象分析産生三種分析模型

　　1、對象模型:對用例模型進行分析,把系統分解成互相協作的分析類,通過類圖/對象圖描述對象/對象的屬性/對象間的關系,是系統的靜态模型

　　2、動态模型:描述系統的動态行為,通過時序圖/協作圖描述對象的互動,以揭示對象間如何協作來完成每個具體的用例,單個對象的狀态變化/動态行為可以通過狀态圖來表達

　　3、功能模型(即用例模型à作為輸入)。

　　三、OOA的主要優點

　　（1）加強了對問題域和系統責任的了解；

　　（2）改進與分析有關的各類人員之間的交流；

　　（3）對需求的變化具有較強的适應性；

　　（4）支援軟體複用。

　　（5）貫穿軟體生命周期全過程的一緻性。

　　（6）實用性；

　　（7）有利于使用者參與。

    四、OOA方法的基本步驟

　　在用OOA具體地分析一個事物時，大緻上遵循如下五個基本步驟：

　　第一步，确定對象和類。這裡所說的對象是對資料及其處理方式的抽象，它反映了系統儲存和處理現實世界中某些事物的資訊的能力。類是多個對象的共同屬性和方法集合的描述，它包括如何在一個類中建立一個新對象的描述。

　　第二步，确定結構（structure）。結構是指問題域的複雜性和連接配接關系。類成員結構反映了泛化-特化關系，整體-部分結構反映整體和局部之間的關系。

　　第三步，确定主題（subject）。主題是指事物的總體概貌和總體分析模型。

　　第四步，确定屬性（attribute）。屬性就是資料元素，可用來描述對象或分類結構的執行個體，可在圖中給出，并在對象的存儲中指定。

　　第五步，确定方法（method）。方法是在收到消息後必須進行的一些處理方法：方法要在圖中定義，并在對象的存儲中指定。對于每個對象和結構來說，那些用來增加、修改、删除和選擇一個方法本身都是隐含的（雖然它們是要在對象的存儲中定義的，但并不在圖上給出），而有些則是顯示的。

                                                           OOD

　　面向對象設計（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也會使你成為一個更好的設計師，它能提供給你很好的工具，讓你能開發出更堅固、更可維護、更可複用的軟體。

                                                               OOP

　面向對象程式設計（Object Oriented Programming，OOP，面向對象程式設計）是一種計算機程式設計架構。OOP 的一條基本原則是計算機程式是由單個能夠起到子程式作用的單元或對象組合而成。OOP 達到了軟體工程的三個主要目标：重用性、靈活性和擴充性。為了實作整體運算，每個對象都能夠接收資訊、處理資料和向其它對象發送資訊。OOP 主要有以下的概念群組件：

　　元件 － 資料和功能一起在運作着的計算機程式中形成的單元，元件在 OOP 計算機程式中是子產品和結構化的基礎。

　　抽象性 － 程式有能力忽略正在進行中資訊的某些方面，即對資訊主要方面關注的能力。

　　封裝 － 也叫做資訊封裝：確定元件不會以不可預期的方式改變其它元件的内部狀态；隻有在那些提供了内部狀态改變方法的元件中，才可以通路其内部狀态。每類元件都提供了一個與其它元件聯系的接口，并規定了其它元件進行調用的方法。

　　多态性 － 元件的引用和類集會涉及到其它許多不同類型的元件，而且引用元件所産生的結果得依據實際調用的類型。

　　繼承性 － 允許在現存的元件基礎上建立子類元件，這統一并增強了多态性和封裝性。典型地來說就是用類來對元件進行分組，而且還可以定義新類為現存的類的擴充，這樣就可以将類組織成樹形或網狀結構，這展現了動作的通用性。

　　由于抽象性、封裝性、重用性以及便于使用等方面的原因，以元件為基礎的程式設計在腳本語言中已經變得特别流行。Python 和 Ruby 是最近才出現的語言，在開發時完全采用了 OOP 的思想，而流行的 Perl 腳本語言從版本5開始也慢慢地加入了新的面向對象的功能元件。用元件代替“現實”上的實體成為 JavaScript（ECMAScript） 得以流行的原因，有論證表明對元件進行适當的組合就可以在英特網上代替 HTML 和 XML 的文檔對象模型（DOM）。

設計模式、技術和直覺構成嚴峻的挑戰。這是選擇程式設計語言之前必須認識到的，盡管不同語言的設計特性可能促進或者阻礙這一轉化。

　　在網絡應用的增長中，一個很重要的部分是小型移動裝置和特殊Internet裝置的爆炸性增長。這些裝置各有各的作業系統，或者隻在某種特定的裝置領域内有共同的作業系統。我們現在還可以一一列舉出這些裝置——家庭接入裝置、蜂窩電話、電子報紙、PDA、自動網絡裝置等等。但是這些裝置領域的數量和深入程度将會很快變得難以估量。我們都知道這個市場大得驚人，PC的興起與之相比不過小菜一碟。是以在這些裝置的應用程式市場上，競争将會相當殘酷。獲勝的重要手段之一，就是盡快進入市場。開發人員需要優秀的工具，迅速高效地撰寫和調試他們的軟體。平台無關性也是制勝秘訣之一，它使得程式員能夠開發出支援多種裝置平台的軟體。

　　我預期的另一個變化是，我們對于代碼(Java)和資料(XML)協同型應用程式的開發能力将會不斷提高。這種協同是開發強大應用程式的核心目标之一。我們從XML的迅速流行和ebXML規範的進展中，已經看到了這個趨勢。ebXML是一個針對電子商務和國際貿易的，基于XML的開放式基礎構架，由聯合國貿易促進和電子商務中心(UN/CEFACT)與結構性資訊标準推進組織(OASIS)共同開發。

　　我們能否期望出現一個真正的面向元件(component-oriented)的語言？它的創造者會是誰呢？

　　Stroustrup: 我懷疑，這個領域中之是以缺乏成果，正是因為人們——主要是那些非程式員們——對“元件”這個意義含糊的字眼寄予了太多的期望。這些人士夢想，有朝一日，元件會以某種方式把程式員趕出曆史舞台。以後那些稱職的“設計員”隻需利用預先調整好的元件，把滑鼠拖一拖放一放，就把系統組合出來。對于軟體工具廠商來說，這種想法還有另一層意義，他們認為，到時候隻有他們才保留有必要的技術，有能力編寫這樣的元件。

　　這種想法有一個最基本的謬誤：這種元件很難獲得廣泛歡迎。一個單獨的元件或架構(framework)，如果能夠滿足一個應用程式或者一個産業領域對所提出的大部分要求的話，對于其制造者來說就是劃算的産品，而且技術上也不是很困難。可是該産業内的幾個競争者很快就會發現，如果所有人都采用這些元件，那麼彼此之間的産品就會變得天下大同，沒什麼差別，他們将淪為簡單的辦事員，主要利潤都将鑽進那些元件/架構供應商的腰包裡！

　　小“元件”很有用，不過産生不了預期的杠杆效應。中型的、更通用的元件非常有用，但是構造時需要非同尋常的彈性。