物件導向與結構化的分析與設計（轉載，不錯的文章）

1 方法背景

結構化思想和物件導向思想雖都產生於20世紀60年代，但它們卻存在根本差別。結構化方法承襲了傳統的編程思想與編程方法，以電腦的計算功能為前提。編寫程式的主要目的是數值計算、問題求解。模組是結構化編程的基本單位，但計算方法(簡稱為演算法)是程式的核心。沃爾森曾提出了一個著名公式：程式=演算法+資料結構。結構化方法只是對傳統程式結構的改進，用三種基本結構來組織程式，使程式結構更為清晰，程式開發更有序、更容易。

物件導向思想則以電腦資訊處理和資訊管理的功能為前提，類比客觀世界的事物及事物之間的聯絡。對象技術的關鍵概念是對象、訊息、類，關鍵機制包括封裝、多態和繼承。與結構化方法相比，對象是軟體模組化的一種新的單位，它代替了基於功能分解方法中的所謂“模組”等傳統的技術。物件導向技術是通過對對象的管理(建立、運行、消亡)以及對象之間的通訊來實現程式功能。結構化方法中模組只是程式一個功能(機械)組件，在程式中完成特定功能或解決特定問題。因此程式中模組通常用函數(function)來實現，完成對輸人資料的加工和計算。而物件導向中的對象則是一個活體(生命體)，它將資料和過程封裝在一起，這同傳統的方法中將資料和過程分別對待和處理形成了鮮明的對比。對象代表現實世界中真實對象的結構和互動作用，在程式運行期間有它的生命週期，並通過訊息相互連信協同完成程式功能。

2 分析問題的方法

軟體分析是軟體工程的一個重要階段。在軟體分析階段，主要確定待開發軟體的功能、效能和運行環境約束；同時提出解決問題或實現功能的方法和途徑，化解一個系統的複雜性，通常有兩種解決方案。化解複雜性的最基本技術是將一個大問題分解為一些容易解決的小問題，待小問題解決了大問題也就解決了。結構化分析方法的核心思想是：自頂向下，逐層分解，逐步求精。結構化分析方法體現在資料流圖和系統結構圖的分解過程中。資料流圖的分解從頂層圖開始，按照每個加工對應一個子圖的分解原則，逐層分解為0層圖、1層圖等。系統結構圖則是從主模組開始，逐層分解為演算法更為簡單、更加容易管理和實現的子模組。

物件導向分析則是採用了另一種自底向上的化解複雜性的方法：抽象。通過抽象，得到系統的一個簡化模型，其中強調系統中某屬性細節，而忽略其它的屬性。物件導向分析存在三個層次的抽象：第一，識別對象及其屬性和方法，這是客觀世界事物的抽象；第二，對對象進行層層歸類，對客觀事物相互關係的抽象，如把相似對象歸為一類，或把子類歸到父類，或把局部類歸整體類；第三，將對象和類進一步抽象歸到某個主題，便於對類和對象的定義和管理。結構化分析方法承襲了傳統數學問題求解的思想，採用了逐步求精的數學演繹方法，有利於資料的加工、計算等問題的解決。但逐步求精的方法不能提供解決一個具體問題的系統的策略或方法。有時，對於某些問題不存在一個自頂向下的方法。結構化程式分析方法對小規模的程式是一種有效方法，但將它推廣至大規模的系統開發中往往會失效，開發人員無法使用這一方法來很方便地重用以前程式的可重用成份。物件導向方法的抽象機制提供了為複雜的軟體系統建模更為自然的方法，特別是能很好地把握對象之間複雜的相互關係，因此物件導向分析技術更加適用於複雜的軟體系統的分析。

3 程式設計方法

結構化程式設計方法與分析方法思路相反，採用了自底向上的設計思想。首先設計底層模組，確定模組內部演算法，設計模組內部程式，並進行單元測試。模組完成之後，再進行模組之間的組裝，進行整合測試。待模組整合測試完成之後，進行確認測試和系統測試，完成設計和調試任務。

物件導向程式設計方法採用了自頂向下的設計思想，先設計父類，再設計子類，並繼承父類屬性和方法。對象是最後在程式運行過程中動態產生。在設計類的同時，另一任務是訊息的設計。並將訊息與類中的方法有機聯絡起來，以便對象在運行過程中能相互連信，共同實現軟體設定的功能。訊息類似於傳統程式設計語言中的函數調用，二者的主要區別是函數調用中所執行的函數是一個單一、公用的實現，而對訊息的響應可以不同回答，這要根據具體對象的方法來確定。這就是物件導向程式設計思想的多態機制。

4 適用場合

結構化方法的實質是問題求解，即結構化程式是由演算法決定的，而演算法是程式員分析設計的。因此結構化方法中，程式的執行過程主要是由程式員控制，而不是由使用者控制。該方法比較適合大型工程計算、即時資料的跟蹤處理、各種自動控制系統等等。

物件導向方法中，程式員設計的是對象屬性及操作方法，但在什麼時間、使用什麼方式操作對象則是完全由使用者互動控制。在互連網時代，電腦已經由一個生產工具逐步演變成一個生活工具，出現了許多完全由使用者控製程序執行過程的應用軟體，比如大型遊戲軟體以及各類管理資訊系統軟體。這些軟體中各種關係比較複雜，適宜使用物件導向的方法來開發。

5 舉個例子(轉)

使用物件導向的思維方法進行設計，其實是一個把商務邏輯從具體的編程技術當中抽象出來的過程，而這個抽象的過程是自上而下的，非常符合人類的思維習慣，也就是先不考慮問題解決的細節，把問題的最主要的方面抽象成為一個簡單的架構，集中精力思考如何解決主要矛盾，然後在解決問題的過程中，再把問題的細節分割成一個一個小問題，再專門去解決細節問題。而一個合理運用物件導向技術進行設計和架構的軟體，更是具備了思維的藝術美感。

舉個例子，要發廣告郵件，廣告郵件清單存在資料庫裡面。倘若用C來寫的話，一般會這樣思考，先把郵件內容讀入，然後串連資料庫，迴圈取郵件地址，調用原生qmail的sendmail命令發送。

如果考慮物件導向方法來做，就不能什麼代碼都塞到main過程裡面，假設我們設計三個類：

一個類是負責讀取資料庫，取郵件地址，調用qmail的sendmail命令發送；

一個類是讀郵件內容，MIME編碼成HTML格式的，再加上郵件標頭；

一個主類負責從命令讀參數，處理命令列參數，調用發email的類。

把一件工作按照功能劃分為3個模組分別處理，每個類完成一件模組任務。

仔細的分析一下，就會發現這樣的設計完全是從程式員實現程式功能的角度來設計的，或者說，設計類的時候，是自低向上的，從機器的角度到現實世界的角度來分析問題的。因此在設計的時候，就已經把程式編程實現的細節都考慮進去了，企圖從底層實現程式這樣的出發點來達到滿足現實世界的軟體需求的目標。這樣的分析方法其實是不適用於物件導向的程式設計語言，因為，如果改用C語言，封裝兩個C函數，都會比Java/C++實現起來輕鬆的多，邏輯上也清楚的多。物件導向的精髓在於考慮問題的思路是從現實世界的人類思維習慣出發的，只要領會了這一點，就領會了物件導向的思維方法。

那麼應用物件導向的方法就逮怎麼做呢？

對於一個郵件來說，有郵件標頭，郵件體，和郵件地址這三個屬性，發送郵件，需要一個發送的方法，另外還需要一個能把所有郵件地址列出來的方法。所以應該如下設計：

類 JunkMail

屬性：

head

body

address

方法：

sendMail() // 發送郵件

listAllMail() // 列郵件地址

這就夠了。

如果說傳統的面向過程的編程是符合機器運行指令的流程的話，那麼物件導向的思維方法就是符合現實生活中人類解決問題的思維過程。

在物件導向的軟體分析和設計的時候，要提醒自己，不要一上來就去想程式碼的實現，應該拋開具體程式設計語言的束縛，集中精力分析我們要實現的軟體的商務邏輯，分析軟體的商務程序，思考應該如何去描述和實現軟體的業務。畢竟軟體只是一個載體，業務才是我們真正要實現的目標。

在設計的時候不應過早的考慮具體程式語言的實現，必須用抽象的方法，和具體實現無關的方法來表達商務邏輯。