l

2016年7月29日 星期五

套用Design Pattern的時間點

July 29 10:10~11:04

螢幕截圖 2016-07-29 10.20.05

 

上週末的「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也不遲。

***

友藏內心獨白:可以用就用,不能用就不要用。

沒有留言:

張貼留言