面向對象分析方法

前言

讀《大象》的這一章節感覺很有指導意義，雖然工程中不能全部實踐，但作為心法來驅動設計是綽綽有餘了。

特質

一切都是對象

在面向對象者的眼裡，一切有名字的東西都是對象，都應該使用對象的觀點來看待它、分析他。哪怕這個東西的名字叫某某業務流程，它仍然應該看作是一個對象，而不是一個過程。這意味著，無論什麼時候都應當採用接下來講述的一些觀點和方法來看待和分析事物。

對象都是獨立的

獨立性是面向對象的一大特點，承認對象的同時就接納了這一觀點。對象與對象之間是天然獨立的，知識在某個特定的場景下，他們的某一個特定的實例才相互的聯繫在一起。

我們獲取和分析對象的手段經常是通過分析某個場景，但是需要知道，對象是離散的，他不是因為該場景而存在的。場景中的對象知識對象『映射』到該場景中的一個側面，我們稱之為對象實例。換言之，通過一個場景，我們僅能得到對象的一個側面的信息。

如果以每一個場景為坐標（維度），那麼對象實例就是對象在該坐標上的投影

每個維度就是更高層的抽象。

 用例：蘋果（假設一筐中有許多蘋果，差異很大）

蘋果顏色，大小，口感是三個維度，那麼簡單的，紅色，中等大小，脆脆的就是框中蘋果們的一個實例。（假設可以根據這三個屬性(方面)來確定是一個蘋果）

要深入瞭解對象，我們經常需要分析很多歌該對象的實例所參與的場景，以獲得對象的多個側面，再通過歸納整理這些對象的多個實例抽象出對象的一般特性。

這就是對象的分析方法，同時也是使用UML來為對象建模時所採用的方法。

從圖2.4中，我們看到對象的產生、抽象並不是拍腦袋得來的。對象來源於場景分析，場景分析越多，我們對對象的瞭解越多，越精確。

有過項目經驗的讀者應該有深刻體會，在做過多個項目以後，會發現在許多項目當中相似的對象或者函數，會產生強烈的想把他們公共化得想法，這就是對象抽象的源動力。

從每個場景看到的僅是對象映射到該場景的一個方面，或者說是一個實例，他僅僅是對象分析的開始。

對象的獨立性帶來的正是對象的可抽象能力和可擴展能力。

請記住，當採用面向對象的方法時，在需求、分析、設計過程中，你所得到的任何一個有名字的東西，不論是用例、類、包、組件等都是獨立於那個場景的，不要將對象局限在那個場景中。

對象都具有原子性

無論在什麼時候，在同一抽象層次上，在分析過程中都應當將對象視為一個不可分割的原子，哪怕這個對象的規模很大。

例如在分析一個商業過程的時候，對象的規模（粒度）大到如銀行、工廠、商場的程度，不論它有多麼巨大，只要我們認為它是對象，它與其他對象交互時就是一個整體，不能分割。

原子性是抽象層次有意義的重要保證，一旦破壞了原子性，則表示在同一抽象層次上的對象不具備同樣的粒度，這使得分析工作陷入混亂。

在分析過程中，對象總有一個邊界，永遠也不應該打破邊界去窺探對象的內部。

形象一些說，對象看上去就像是一個個的雞蛋，蛋殼就是對象的邊界。在分析對象的過程中，我們對它的所有理解都是來自蛋殼。如果因為我們好奇心太重試圖瞭解殼以內的世界，衝動的打破了邊界，嗯，的確看到了，好奇心得到了滿足，不過很快就後悔了。因為雞蛋被破壞了，一灘黏黏糊糊的蛋清弄髒了手，很難收拾：P 糟糕的設計就像一堆破了殼的雞蛋，一片混亂。

我們應當將分析過程中得到的所有對於對象的認識附加在對象邊界上，在實現這個對象之前不理會其內部的細節。這就是傳說中的面向介面編程：P

對象都是可抽象的

對象有著許多個不同的方面。

一般來說，對象參與一個場景時會展現出某一個方面。總可以將對象的某一個方面抽象出來，讓其作為對象的一個代碼來參與場景交互。通常這種抽象會以介面來命名。

在分析過程中，得到的任何一個對象都有特定的方面可作為抽象。因為對象總是從場景分析中得到的，它在場景中肯定戰象了一個方面。

對象所具有的方面，或者說對象所參與的場景越多，對象越有抽象價值，反之則越沒有抽象價值。因此在分析過程中，應當關註於那些參與了很多場景的對象，他們往往是分析設計中的重點以及成敗關鍵。

對象都是有層次的

層次越高，其描述約粗略但適應能力越廣；層次越低則描述越精確但適應能力越下降。在分析過程中，應當根據問題領域的複雜程度設定多個抽象層次，在每個層次上使用合適的抽象程度的對象描述。這將有助於顯著的減少分析的難度和工作量。

不論是在需求、分析還是設計過程中，都應當具備抽象層次的觀點。從需求到設計的過程已經是幾個不同的抽象層次，筆者要說的是，在其中的一個階段，例如需求階段，仍然可以再多分幾個抽象層次來說明。具體分多少抽象層次應視問題領域的複雜程度而定。

總結

獨立性、原子性、抽象性和層次性是面向對象分析時應當遵循的一些原則和方法。在實際工作中，圖2.5所示的幾個方面是需要考慮的，如果該對象是一個關鍵對象，則應當儘量說明途中所示方面的內容。