物件導向的分析與設計（收藏）

        什麼是對象？對象由映象和意向組成。所有的東西——包括物體、事物、活動、關係以及由它們組成的混合體都可以看成是對象嗎？對。對象的任何子集都可以看成是對象嗎？對，對象具有可分解性，也有可組合性。

什麼是類？類是對象的一般性描述。類和對象有什麼區別？正如你所見，類描述了對象的特性和行為，也即對象的映象和意向。類是語言描述，由它向我們表達對象資訊，或者我們通過定義類來確定對象的特性行為。對象根據類描述而被構造。

什麼是物件導向的分析？採用物件導向的思想，對系統進行分析，根據使用者需求提取出系統應具有的屬性和行為。

什麼是物件導向的設計？將分析的結果用某種易於轉化為編碼或易於理解的形式表達出來。我們常見的有流程圖，ER圖，資料流圖等。分析和設計是兩個相互結合、漸進的過程。

[注意] 本文不對“系統”和“對象”作區分，系統被當作對象來處理。所以，文章中出現的“對象”和“系統”可能是指同樣的東西。

文章僅代表作者的觀點。如果你同意作者的觀點，或者覺得文章表達出來的思想不錯，歡迎你與作者交流心得體會；如果你覺得文章存在很多錯誤，或者說其思想本身並無多大可取之處，歡迎提出批評意見。

關於作者對物件導向的理解，請參見《也談物件導向》和《再談物件導向》兩文。本文是以上兩篇文章的延伸。

圖書管理系統

這是作者曾經參與的一個項目。該思想在後來的項目中都得到充分的體現。為了便於說明，例子在原來的基礎上作了簡化。

1．問題描述

圖書管理系統由兩大部分組成，即資料存放區和操作管理兩大部分。資料庫包括書籍資料庫、讀者資料庫。管理方麵包括借書/還書/查詢管理、讀者/書籍管理。

2．任務與規則

圖書管理系統處理讀者的註冊與登出，新書入庫/舊書出庫，書籍的借閱與歸還，以及讀者資訊/書籍資訊查詢等。

規則是系統在運行過程中，管理各種操作應當遵守的約定。如某讀者A，讀者類型為教師，該類型對應的規則是：最大借書數目為a，最長借書期限為b等。

3．物件導向的系統分析

經過初步分析，系統的E—R圖如下。方框圖表示實體，直線表示關係。每個實體都可以看作是系統屬性。所謂系統屬性，是指系統中可以直觀表示出來的組成部分，它是系統的一個劃分，跟後面介紹的對象劃分有關係又有區別。

如你所見，為了降低對象間的耦合度，“借書”和“還書”只與“書籍管理”進行通訊。同時對讀者資訊的更新操作由“書籍管理”通知“讀者管理”進行。

如何進行系統分析

怎麼樣對系統分析，沒有一定的標準。很多軟體工程著作都給出了步驟，甚至詳細規定了你每一步要做的事情。但實際上，你所面對的每一個問題都是不相同的，沒有一套萬能的方法，能夠使你的工作變得既簡便，又有最高的效率，還能達到最好的結果。那麼，能指導你的，是你的思想，你的經驗。同樣，我也不能在這裡說你應當怎樣，不應當怎樣。我只希望通過本例來表達系統分析的一些基本思想。

首先，提取系統屬性。通過參與某校圖書館的日常工作，及工作人員的介紹，我們知道了圖書館的一般工作流程，瞭解了圖書館的各個組成部分，及各個部門。根據這些資訊，我們提取了該系統的屬性：（1）書庫及書籍出/入庫管理部門；（2）讀者資訊檔案及管理部門；（3）還書櫃檯；（4）借書櫃檯；（5）讀者及書籍資訊查詢室。

其次，確定系統行為。圖書館需要做的工作有：讀者的註冊與登出，新書入庫/舊書出庫，書籍的借閱與歸還，以及讀者資訊/書籍資訊查詢等。

還有很多細節問題，可能在開始時無法考慮周全。我們要給這些問題留出解決空間。

不管你採用什麼樣的方法進行分析，這兩個過程一般都會有的。

以看出，這個對象還是個複雜的大對象。我們不能用簡單的一個或幾個類來描述它。我們也不能一下子設計出成百上千個類來直接實現它——那樣，項目會進入到一個無法控制的地步。

4．對象劃分：分而治之

既然是一個複雜物件，我們就不可能直接實現它，而是採取分而治之的思想將大規模問題劃分成相對獨立的小規模問題，逐個擊破，來解決大問題。分治思想在很多領域都有廣泛的應用，它是實現問題由複雜向簡單轉化的一個有效方法。在我們的軟體設計領域，很多項目都要涉及都眾多方面，而且其間關係也異常複雜。建立適當的模型，使我們的問題更易於理解，易於實現，易於維護，是每個分析設計人員的目標。分治思想是很好的思想，特別是在與物件導向思想結合情況下。在本例中，圖書管理系統被劃分成以下幾個子系統：

（1） 借書管理系統；

（2） 還書管理系統；

（3） 查詢系統；

（4） 讀者管理系統；

（5） 書籍管理系統。

如何進行對象的劃分

對對象進行劃分，也是沒有一定的標準的。從分析人員的角度，它主要取決於三個方面：1、分析人員對物件導向思想（或其他指導思想，採用物件導向方法就是物件導向思想了）的理解；2、分析人員的系統分析經驗；3、分析人員對系統構架、使用者需求的把握程度。如何將一個大系統劃分成相對獨立、易於處理的小系統？不同的人可能會得出不同的結果。一般採用E-R轉換規則，即將實體看作為一個子系統。但這並不適用於所有的情況。雖然劃分沒有一定的標準，但評判卻是有一定的標準的，即：1、子物件之間獨立性要高，即耦合度盡量達到最低，（理想的情況是達到組件化的程度）；2、子物件相對其他劃分方法，更易於處理。所以對於複雜的大系統，一般都要經過多次的嘗試，以盡量能找到較優的劃分方案。對於比較簡單的系統，E-R轉換也能的到較為滿意的劃分。

其實，我們要劃分的子系統，都已經包含在系統分析所得出來的結果——系統屬性中。你可以將每個系統屬性當作子系統；但這樣做可能不是一個好的劃分。你可以由這步開始進行對象劃分。你可能要合并或分解某些系統屬性。

5．制定協議

子物件已經劃分，我們如何來實現它們之間的聯絡？這就要求我們為對象模組間的通訊制定一個協議。通訊協定是實現模組低耦合的一個有效方法。一般有兩種方法可以解決這個問題。

(1) 採用訊息機制。即一個對象向其協作對象發送訊息，通知該對象進行某種操作。例如，它們的一種使用格式可能是這樣的：

PostMessage(FROM SRC, TO TARGET, MSG CODE, PARAM1,PARAM2...)

在這種情況下，就要求我們定義各種訊息，以及對應不同的訊息時，各個參數的意義。如，一個借書訊息格式可能如下：

PostMessage((FROM)借書系統,(TO)書籍管理系統,(MSG CODE)“借書”,（參數1）讀者代碼（借書證號），（參數2）書籍館藏號，（參數3）錯誤資訊，RESERVED1,RESERVED2,…)

書籍管理系統在接收到這條訊息後，分別向讀者管理系統和書籍管理系統發送相應訊息。兩者都成功，則再向借書系統返回成功資訊，否則返回出錯資訊。

(2) 採用介面。既通過公布對象的介面來向外界提供相應的功能。如，假設書籍管理系統向外界提供了IBookMS介面，那麼在借書系統中借書操作的實現看起來應該像這樣：

IBookMS bms;

Result rs=bms.Borrow(讀者代碼，書籍館藏號);

當然，在進行借書操作前應先註冊借書系統實體，如，可能是這樣的形式：

RegisterBookMS(IBookMS ibms){ this.bms = ibms； }

介面可有多種類型：單介面，多借口。單介面是指一個對象為向外界發布自己的功能而作的描述；而多介面是指多個協作對象系統同時都需要實現介面，但並不常用。

兩種方法各有各的優點。對於前者，源系統可以向目標系統發送任何訊息，而不管它能否識別；目標系統只要處理自己感興趣的訊息。這就使得進行增加系統功能等修改時，只需要增加新訊息，而不必修改原有訊息集。而對於後者，使用簡單直觀方便，不用去記住不同訊息對應的參數含義，不會出現訊息丟失使得操作無法完成等的情況。但是在進行系統維護時，可能要修改介面或增加介面，很有可能導致版本控制異常。所以採用哪種方法需要視情況而定，可能選其一，也可能二者兼用。

什麼時候使用介面

有些情況下，程式員可能會有兩種關於介面的認識，一是很少或從來不用介面，認為介面似乎並沒有什麼用處，不用介面也能完成任務。二是喜歡濫用介面。確實在很多情況下介面為我們在程式設計時提供了一定的靈活性。但這會造成一些問題，你的代碼會因此而變得混亂不堪，難以管理，難以理解，也會使得問題複雜化。

那麼究竟什麼時候該使用介面？從某個角度說，介面是用來描述對象所具有的特性行為的，是對象代理，可以成為對象間聯絡的紐帶。當兩個對象相對獨立，但又要進行必要的通訊時，就可以使用介面來協助。此外，不要隨意使用介面，因為那樣可能給你帶來問題。下面我說明“必要”的含義。

我們在劃分對象之後，就開始對對象的行為特性做進一步的分析處理。如，在上面的例子中，借書系統向書籍管理系統提出借書請求，這是“必要”的通訊。但是，在時間處理時我們要考慮讀者代碼（借書證號）和書籍館藏號的合法性。那麼，這步合法性檢驗，應該在借書操作之前由借書管理系統進行呢，還是在借書操作時由書籍管理系統進行？似乎兩種方案都可以。但是，前種方案會破壞對象劃分規則：盡量低耦合。因為，在邏輯上應該由其協作對象處理而不是必要由它處理的事情被它處理，將增加該對象和其協作對象間的耦合度，因為我們希望盡量減少跨對象調用。在上例中，合法性檢驗放在bms.Borrow (ReaderNumber,BookNumber)方法中，比起在bms.Borrow之前調用如bms.IsIllegalNumber的合法性檢驗方法更能降低對象耦合度。因此，我們把前一種情況稱為“非必要通訊”。我們在設計對象的行為特性時，要盡量減少這種非必要通訊的發生。

我們可能經常分析名家名作。每當遇到介面時，就要注意它的兩端是什麼，它所擔負的使命是什麼。注意到這一點，對我們瞭解別人的設計思路是很有協助的。JAVA類庫採用了良好的設計模式，它裡面就使用了很多介面。不妨去研究研究，也許你會有所啟發。

6．逐步求精

你參與了圖書管理系統的分析。現在，主管將其中的一個子系統交給你完成，假設就是書籍管理系統。你清楚地知道這個系統應該向其他系統提供什麼功能，也知道除此之外其自己還要實現什麼功能。那麼，從現在開始，你和你的小組成員開始對分配下來的子系統進行分析設計。

BOOK

DB

DBMS

出庫

入庫

借出

歸還

查詢

IBookMS : Wrapper封裝類

其實對這個系統來說，到這個程度已經非常簡單了。我們可以通過幾個類實現相應的功能了。如果你的系統還是比較複雜，那麼對該系統繼續進行3、4、5、6的步驟，直到所有的子系統都比較簡單易於實現為止。

7．分散式處理

現在的系統，恐怕很少有針對單機的。在設計電腦通訊模組時（假如需要自己實現），要高度封裝底層細節。具體我也就不多說什麼了。

[總結]

物件導向的系統分析設計，看起來其實也很簡單，步驟大概如下：

（1） 從項目開始，進行步驟（2）。

（2） 對系統進行分析，如果它在一定的要求下可解決，則停止分析，進行設計；如果它在一定的要求下不可解決，則對它進行劃分。

（3） 步驟（2）如果有分析結果，則對其中每一個子物件，進行步驟（2）。

邊界條件（也即上面提到的“一定要求”，對象劃分的原則）：

子物件之間獨立性要高，即耦合度盡量達到最低，（理想的情況是達到組件化的程度）；

子物件相對其他劃分方法，更易於處理（如實現，維護等）。

說得這麼簡單，在實際的工作中可就沒這麼簡單了。你可能會碰到方方面面的問題；甚至可能會被好多細節問題淹沒。有時候看上去一馬平川，出現問題時可能山重水複，不能前行半步。說到底，物件導向思想（或是任何其他思想）只能指導我們工作，讓我門不至在繁難複雜的問題中迷失方向；它不是萬能的，不會因為採用了物件導向的思想進行分析設計，項目就一定會成功（儘管它確實能在一定程度上使問題簡化）。

寫到這裡，作者還想多說幾句。任何思想，都是為瞭解決某一類問題而出現的，本身並無多大的一般性。所以，面對如潮水般湧來的新思想、新技術，不要被嚇著，也不要盲目去追求。選擇合適的，與你原有的思想、技術進行比較，揚棄，整合，變成自己的思想。好了，你現在瞭解物件導向思想了吧？可以去看看其他東西了，CMM，UML算老的了，現在比較熱的，AGILE，XP，MDA，AOP，都不知道是些什麼。