OOA（面向對象分析）、OOD（面向對象設計）、OOP（面向對象編程），這3個概念，對於我們JAVA程序員來講，或多或少應該都有所了解，或者說至少都聽說過。但是要談到對其理解，可能對於多數入行不深的從業者來說，確實不是那么容易做到。特別是對於絕大多數的3年以內的低中級軟件工程師而言。因為他們的工作更多是需要按照項目經理分配的任務來編寫功能代碼，很少有多余的時間去閱讀或者思考一些概念性的東西。說起這個問題，我也在網絡上也搜索過很多的資料，大多摘錄至書籍，比較官方化。讓初學者無從理解。
為了廣大的新從業者或者應聘者，在這里，我們以一種實例的方式來對這3個概念進行重新的闡述：
業務場景：
建行卡持有者，張三與李四兩人，現在需要張三給李四轉賬人民幣5000元整。按照業務分析后的流程圖如下:
對於分析業務流程，常見的2種：面向過程分析（POA），面向對象分析（OOA）
面向過程分析（Procedure Oriented Analysis）：是一種以過程為中心的編程思想，以數據流向為主要導向。為了解決問題，將解決問題的業務過程，按照一定的順序划分成為一個又一個的事件，然后再封裝成一個又一個的函數，最后由一個函數統一的按照順序一步一步的調用即可。在面向過程分析中，順序很重要，要實現功能只需要按照一定的順序相互調用函數即可。
上述業務場景按照面向過程分析出來的結果就是：
- 程序檢查張三卡中余額是否足夠5000元人民幣（事件1，滿足則調用事件2）
- 程序從張三卡中扣除5000元人民幣（事件2）
- 程序向李四卡中加入5000元人民幣（事件3）
- 程序檢測李四卡中是否正常入賬（事件4，滿足則結束整個業務）
- 程序向張三卡中加入5000元人民幣（事件5）
在上述過程中，我們將這個業務過程，分成了5個步驟，也叫做5個事件，那么如果需要在程序中完成該轉賬業務的話，那么我們只需要按照1-2-3-4-5這樣的順序依次調用函數方法即可。在這個過程中，你會發現我們函數調用的順序一定是不能變化的，變了就出問題了……
面向對象分析（Object Oriented Analysis）:是一種以對象為中心的編程思想。利用從問題域中的詞匯表中找到類與對象。那么說到這里，很多人對問題域又不是很清楚了，問題域：說的簡單直接一點，問題域就是客戶告訴你的要求，他要干什么。問題域並不特指需求，很多時候，客戶所提的需求很多地方都有關聯，所以在很多場合，客戶所提的需求，還需要需求分析師多角度的幫助客戶理清與完善。那么在客戶需求范圍中，衍生出來的他想要告訴你做的事，就是問題域，包括后期需求發生的變化，同樣隸屬於問題域的范圍。
用一個圖來表示：需求分析文檔，規格說明文檔，以及程序之間的關系：
從上述業務場景的分析中，我們可以抽離出的類與對象有：
抽離出來的類型有：匯錢者類，收錢者類，貨幣類。而張三只能算是匯錢者類中的一個實例，也被稱之為匯錢者對象，李四只能算是一個收錢者類中的一個實例，也被稱之為收錢者對象。那么額度為5000的人民幣也只是貨幣類的一個具體實例。通常匯錢者類，收錢者類，貨幣類，我們都統一稱之為：領域模型類，張三，李四，5000元人民幣我們都統一稱之為：領域對象。作為面向對象分析來說，我們最為重要的就是要分析出領域對象的行為。領域對象的行為主要是為后期的面向對象設計（OOD）提供接口依據，而屬性作為分析階段不是我們的重點。
就上述3種領域對象而言，張三這個實例，可以查詢自己卡中余額，可以從余額中取出5000元，也可以將外來的錢加入到自己的賬戶中。
李四這個實例，可以查詢自己卡中余額，可以將外來的錢加入到自己的賬戶中。而5000元人民幣只是數據的傳輸攜帶者，沒有任何行為可言。
在JAVAEE項目中，組織業務邏輯的方式：事務腳本（面向過程設計 POD）、領域模型（面向對象設計 OOD）
事務腳本（面向過程設計 POD）：它是純面向過程的一種組織業務邏輯的方式，在JAVAEE項目，是一種非常常見的設計方式，做法很簡單，將POA分析后的結果封裝成JAVA對應的方法即可，然后在業務層中統一按照順序調用接口。將領域對象（人民幣）去掉行為，只保留屬性即可，用於數據傳輸。以數據流向為主要導向。
按照上述的業務場景來設計：保留失去行為的領域對象（人民幣），同時抽離出一個業務層的接口類，多個持久層的數據訪問接口類，在業務層接口中提供一個統一的業務調用方法transferAccount(),在數據庫發生關系的持久層，提供一系列事件方法：queryBalance(),reduceBalance(),increaseBalance();使用UML類圖表示為：
當然還有一系列的表示手段，比如：包圖，對象圖，序列圖，用例圖…… 這里就不一一設計了。
領域模型（面向對象設計 OOD）（Object Oriented Design）：主要是正確有效的構造出復雜系統的抽象結構，將面向對象分析后的結果，作為面向對象設計的模型，通常用於展示被設計系統的邏輯模型（業務邏輯如何設計），物理模型（系統如何划分，層次如何划分，如何部署……），靜態模型（組成系統的元素：類，接口）和動態模型（對象的調用……）。將OOA分析的結果作進一步的規范化整理，以便能夠被OOP直接接受。
概念可能比較生硬，那么說的直白點，設計階段的任務就是：
- 按照面向對象的方式將系統分解成不同的模塊化，或者系統再次划分為子系統，直到划分到可設計的最小粒度為止【垂直分塊，水平分層】。
- 使用不同的表示方法來展示被設計系統的邏輯模型（業務邏輯如何設計），物理模型（系統如何划分，層次如何划分，如何部署……），靜態模型（組成系統的元素：類，接口）和動態模型（對象的調用……）【常用的表示法手段：UML各種圖形】。
需要注意的是：層次結構並非就一定是三層結構，也可以是多層，具體分幾層需要根據項目的復雜度來決定，如果沒有過多的業務邏輯，只有簡單的CRUD的話，那么三層結構足以應付一切。
按照上述的業務場景來設計：對於領域邏輯來說，三層結構就不能滿足其業務邏輯復雜度了，可能這時整個系統可能是四層，五層，或者多層……，我們這個例子，暫時定為四層結構：控制層、業務層、領域邏輯層、數據訪問層。在設計領域對象時，保留失去行為的領域對象（人民幣），轉錢對象，收錢對象，同時抽象出一個業務層的業務接口用於簡單的調度業務邏輯，多個持久層的數據訪問接口類。
在OOA階段，我們分析出張三這個實例，可以查詢自己卡中余額，可以從余額中取出5000元，也可以將外來的錢加入到自己的賬戶中。那么它就應該對應着對應的3種行為方法。
李四這個實例，可以查詢自己卡中余額，可以將外來的錢加入到自己的賬戶中，那么它就應該對應着對應的2種行為方法。而5000元人民幣只是數據的傳輸攜帶者，沒有任何行為可言
如果采用UML中類圖的表示法來看，圖形應該如下：
（在同一個圖中，相同名稱的元素代表同一元素）
在這張圖中，我們的層次就是4層結構，甚至我們還可以再分為5層，6層等，所以一般領域模型適用於業務需求較為復雜的情況。業務層僅僅是為了梳理業務流程，而真正的業務邏輯則交由領域層的領域對象之間相互調用對方的方法來實現業務邏輯。比如要轉錢，就需要轉錢者領域對象，減少自己的余額后，調用收錢者領域對象，添加自己的余額。當然真正的銀行轉錢復雜度，絕對遠高於這個場景。 還需要使用到事件驅動模型，以及消息隊列等一系列的技術，當然具體情況具體分析。
面向對象編程（OOP）
面向對象編程（Object Oriented programming）：將面向對象設計后的抽象，采用面向對象的方式來實現的方法，就叫做面向對象編程。在這種方法中，程序被組織成許多相互協作的對象，每個對象都是一個類的實例。利用對象構成業務邏輯的組成基本元素（組合模式的層次結構），而不是采用算法。組成程序的基本元素是一個又一個的基礎組件（類），那么組件就是我們層次結構所對應的接口或接口的實現類，那么程序就是由一個又一個實現類的實例相互協作來完成業務邏輯的實現。
總體來說： 面向對象分析的結果可以作為面向對象設計的模型，而面向對象設計的結果則可以作為面向對象編程的藍圖，應用程序需要由編程才能實現。