實戰系列『影像處理軟體設計』- [8] 物件導向方法：設計模型(上)

經過領域模型的分析後，已經可以看出「物件導向」的雛型了，但領域類別無法直接拿來做程式設計，因為它只是從「使用案例模型」中萃取出來、映射業務領域的概念，而非真正意義上的軟體類別。

一、何謂設計模型

「設計模型」就是用來連結「領域類別」到「軟體類別」的轉換，這就是「物件導向設計階段」的主要任務。

設計階段是整個物件導向分析和設計的關鍵，它將輸出「設計模型」，並綜合各種方法與技巧。

設計並沒有一個量化的標準，這代表沒有標準答案，物件導向的設計更像是一門藝術，不過它也是有一定的規律和方法可尋。

二、設計模型總覽

設計模型主要包含：靜態模型和動態模型。

靜態模型又稱為「類別模型」，主要關注系統的「靜態」結構，描述系統包含的類別、類別的名稱、職責、屬性、方法，以及類別與類別之間的關係。

動態模型關注系統的「動態」行為，描述類別本身的一些動作，或者狀態變化，以及類別之間如何配合，才能完成最終的系統功能。

只有結合靜態與動態模型，才能真正描述清楚一個系統。

• 靜態模型：類別的宣告，包括類別、屬性、方法名稱。
• 動態模型：類別的實作，每個方法內部的實作過程。

因為動態模型是描述具體功能的實作過程，看起來會跟「程序導向」的分析方法類似，但它本質上還是「物件導向」，描述的是各個物件之間如何配合與協作。

動態模型必須在靜態模型的基礎上設計，靜態模型的變化也會影響到動態模型。

三、類別模型設計

「類別模型」是整個物件導向設計模型的核心。

進行物件導向類別設計，第一個要解決的問題是：類別從哪裡來？

領域模型中的「領域類別」，便是設計類別中「軟體類別」最好的來源；透過「領域類別」啟發設計最初的「軟體類別」，具有下列幾個明顯的優點：

• 軟體類別來自領域類別，領域類別來自使用案例，使用案例來自客戶；一環扣一環，軟體類別的正確性得到保證，不用擔心主觀臆測所帶來的問題。
• 領域類別到軟體類別的轉換非常簡單，只要掌握基本的物件導向知識就能完成。
• 不需要參考其它系統，不用擔心沒有參考物時無法設計的問題。

(1) 領域類別映射

• 類別篩選

「軟體類別」是軟體系統內部的一個概念，而「領域類別」則是業務領域的概念，並不是每個領域類別最終都會體現在軟體系統中。

• 名稱映射

篩選完成後，將每個領域類別都用一個軟體類別相對應，名稱保持一致即可，別擔心這樣的設計品質不高，目前只是一個開始工作。

• 屬性映射

透過名稱映射得到軟體類別後，接下來就是設計類別的屬性；由於領域類別已經有屬性，因此照搬過來即可。

• 提煉方法

軟體類別的屬性設計完成後，接下就是設計軟體類別的方法；類別方法的設計也是從已有的模型推導出來。

鎖定「使用案例模型」來找到類別方法，其重點就是「找動詞」。

我們之後會以「影像處理軟體」為例，說明如何透過「找動詞」這種技巧找到軟體類別的方法。

(2) 應用設計原則和設計模式

物件導向領域經過幾十年的演進，已經發展出很多成熟的指導方針和方法，以利於評價和規範物件導向設計；其中最具代表性的就是「設計原則」和「設計模式」。

• 設計原則

當提及物件導向領域的設計原則時，其實都是在談論 Robert C Martin 的 「SOLID 原則」。

設計原則也是一個判斷標準，應用設計原則的根本目的是要「保證可擴充性」。

設計模式的本質也是為了提高可擴充性；這也是為什麼透過領域類別映射後，還要繼續應用「設計原則」和「設計模式」的主要原因，根本上都是為了提高設計的可擴充性。

後續將以「影像處理軟體」為例，看看如何應用設計原則。

• 設計模式

相較於設計原則，設計模式更加普及與流行；一般談到設計方法時，都會先想到設計模式。

通常談論設計模式時，其實都是指 GoF (Gang of Four) 所講的設計模式。

設計原則和設計模式是互補關係：設計原則主要規範「類別的定義」，而設計模式主要規範「類別的行為」。

• 設計原則：類別的靜態設計原則。
• 設計模式：類別的動態設計原則。

後續將同樣以「影像處理軟體」為例，說明如何應用設計模式來進行最佳化設計。

(3) 拆分輔助類別

拆分類別的主要目的，是為了使撰寫類別時能夠滿足一些框架或規範的要求；例如常見的 MVC 模式，拆分成 Model、View、Control 三個元素等。

只要將設計出來的類別，按照規範要求，對應拆分即可；這僅是為了滿足框架或者規範的要求，本身並不是設計，而是實作的一個步驟，所以一般都不需要將拆分的輔助類別體現於類別模型中，只在設計程式時拆分即可。