最近在學習王翔老師的<設計模式:基於C#的工程化實現及擴展>，突然想到一個問題：我們什麼時候應該用設計模式？
問題一：什麼時候該用？
問題二：什麼時候不該用？
問題三：該用哪一個模式？
問題四：怎麼分析“用”與“不用”的利弊？
首先，我們要搞清楚設計模式出現的目的：爲重複問題提供統一的解決思路。那麼，哪些問題是重複問題？在軟件開發過程中，最大的“重複問題”就是新的業務需求要求我們不斷對系統進行修改。這裏面就涉及三個問題：1) 哪些情況要求我們不斷修改我們的系統；2) 如何使改動的工作量最小；3) 如何使改動的影響範圍最小。
假設系統的業務需求僅包含一種付費方式，例如通過調用付費網關的API進行付費，就沒有必要採用什麼設計模式。如果某一天客戶要求增加一種新的付費網關，那麼我們就需要考慮其他客戶也有類似的需求。如果有，則有必要考慮是否引入設計模式，如果沒有，則沒有必要引入設計模式，因爲大家都知道，設計模式屬於複雜設計，會導致難以維護。在我所服務的產品裏，其使用了三種類型的付費網關：第一種是通過web service的方式，第二種是通過API的方式，第三種是redirect 到第三方付費網站的方式。每一種類型又有很多的付費服務提供商，他們對參數的要求也不一樣。複雜的業務需求，要求我們必須使用設計模式去適應日後不同的客戶需求，以及降低日後的維護成本。
什麼時候不該用設計模式？就是簡單的問題不要用過度設計。
什麼時候該用設計模式？就是將複雜的問題簡單化。
“用”與“不用”的利弊，可以從後期維護成本的多少來衡量。
軟件開發過程中常見的“複雜問題”：
1、新增字段導致很多地方需要修改，如UI Layer, DAO Layer和Business Layer。
2、對以前存在的業務流程插入新的邏輯分支。
3、對以前存在的業務邏輯，增加另一種實現方式。
4、對現有系統增加新的功能。