May 23 16:48~17:50
沒想到這個主題會出現第二集，第一集的內容在這裡，有興趣的鄉民可以複習一下。在寫了第一集之後，Teddy開了三次「Design Patterns這樣學就會了：入門實作班」以及一次「Design Patterns這樣學就會了：進階實作」，對於這個問題體會又有些不同。
基本上，可以從兩個角度來思考：
- 有多少資源：如果你只願意投資10小時的時間來學設計模式，那麼可能了解一下Observer、Factory Method、Command的內涵就差不多了。如果你有50小時，又有熟悉設計模式的人可以教你，那麼把GoF的23個設計模式都練習過一次應該是綽綽有餘了。
- 想成為什麼樣的人：如果你立志當一位「傳統」的開發人員，那麼也許可以完全都不知道設計模式。如果你想當technical leader或是軟體架構師，那麼多學一些設計模式絕對是有好無壞。
***
有些人會認為，GoF的23個設計模式有些使用的時機並不多，有些因為太常用了，已經變成許多程式語言內建的一部分，例如Java有支援Observer、Prototype、Iterator、Proxy。對於這種太偏門或是太常用的設計模式，其實沒必要特別去學習。但是最近的兩次經驗，卻讓Teddy更堅信在第一集所下的結論依然成立：「有機會的話最好是每個都學。當然，學了不一定會用到，但是沒學，幾乎可以肯定用不到」。
經驗一
話說有一位來上過Teddy「Design Patterns這樣學就會了：入門實作班」與「Design Patterns這樣學就會了：進階實作」的學員，有一天告訴Teddy，他原本覺得Iterator不太會用到，因為Java的collection物件都已經支援這個設計模式，他自己也不會去開發新的collection物件。但當他在課堂上實作了Iterator之後，才赫然發現原本他工作中的某個模組，可以套用Iterator減低程式的複雜度，也可以讓客戶端的程式更容易使用他這個模組。
後來他花了一些時間把系統重構，實作了Iterator這個模式。
***
經驗二
有一次在上「Design Patterns這樣學就會了：入門實作班」的時候，講到Composite模式，有一個學員就問Teddy，他們公司的組織表可以套用Composite模式，但是他一直都有一個困擾，就是他們經常需要用不同的方式來瀏覽組織表，並且根據特殊的條件來產生不同的統計資料。這個問題怎麼用Composite模式解決？
這位學員的問題聽起來應該無法直接用Composite模式解決，一種可能的方法是套用Visitor模式，將這些特殊且經常修改的條件寫成個別的Visitor。不過因為當時上的是「入門班」，而Visitor是在「進階班」才會教到，所以當時Teddy也只能建議這位學員回去自己讀
***
其實Teddy發現很多程式設計師的桌上，都有設計模式的書，雖然不一定是GoF這一本。加減看總有一天功力會變強。
***
友藏內心獨白：花錢來上Teddy的課最快
。
），素材準備比較容易。目前Teddy已經準備了一份約180頁左右的草稿（主要從搞笑談軟工部落格文章挑選出來，但尚未進行編修）。
。
？
。
。
