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

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

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

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

 

設計模型總覽


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

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

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

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

靜態模型:類別的宣告,包括類別、屬性、方法名稱。

動態模型:類別的實作,每個方法內部的實作過程。

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

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

 

類別模型


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

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

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

*軟體類別來自領域類別,領域類別來自使用案例,使用案例來自客戶;一環扣一環,軟體類別的正確性得到保證,不用擔心主觀臆測所帶來的問題。

*領域類別到軟體類別的轉換非常簡單,只要掌握基本的物件導向知識就能完成。

*不需要參考其它系統,不用擔心沒有參考物時無法設計的問題。

 

1. 領域類別映射


-類別篩選

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

-名稱映射

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

-屬性映射

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

-提煉方法

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

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

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

 

2. 應用設計原則和設計模式


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

-設計原則

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

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

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

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

-設計模式

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

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

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

設計原則:類別的靜態設計原則。

設計模式:類別的動態設計原則。

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

 

3. 拆分輔助類別


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

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

 

arrow
arrow

    OtakuYeh 發表在 痞客邦 留言(0) 人氣()