套用Design Pattern的時間點

July 29 10:10~11:04

 

上週末的「Design Patterns這樣學就會了–入門實作班」有學員問：「應該在什麼時間點套用設計模式（design pattern）？」這個問題Teddy曾經在〈直接套用Pattern還是Refactoring to Pattern？〉談過，今天從軟體生命週期的角度再來討論一次。

廣義的說，有兩個套用design pattern的時間點：

• 設計階段：如上圖所示，從物件導向分析與設計流程來看，在了解客戶需求也就是完成分析工作（建立use case mode與domain model）之後的設計階段（建立design model），此時是第一個套用design pattern的時機。例如，你要開發一個給DevOps使用的監控雲端服務軟體，在分析完問題之後，在設計階段你發現這個軟體可以套用State模式來管理被監控對象的狀態。當被監控的對象狀態發生異常時，可以套用Observer模式通知其他物件。在需求很明確的狀況下，可以直接套用設計模式而不至於產生過度設計的問題。
• 實作之後：有時候在設計階段套用design pattern的「作用力（force）」還不是很具體，只能先利用基本的物件導向設計方法來設計物件與分配責任。在實作幾個功能（use case或user story）之後才慢慢發現可以藉由重構方法來套用design pattern。
  

***

把套用design pattern的時機分成設計階段與實作之後看起來很簡單，但實際上這個過程還要再放到迭代與增量開發的流程中來討論。也就是說，每一個迭代（iteration）或衝刺（sprint）的每一個user story開發都包含了分析、設計、實作、測試等階段。在這種情況下，因為每個user story的範圍與大小相較於傳統use case或其他需求單位要來的小很多，所以相對來說比較不容易在專案初期的「設計階段」（還沒寫程式碼之前）就直接套用design pattern。換句話說，相較於傳統waterfall式的開發流程，在敏捷開發中先把程式寫完再重構成design pattern的機會可能比較多。

總之，需求如果已經很明確，要解決的問題也清楚，不需要先把自己變笨之後再將設計重構成design pattern。反之，先讓系統可以動，等需求明確之後再重構成design pattern也不遲。

***

友藏內心獨白：可以用就用，不能用就不要用。