**：
最近，同事、朋友跟我聊天的過程中，提到了設計模式方方面面的問題。隨著物件導向、敏捷開發的深入人心，越來越多的程式設計師希望能夠借助設計模式，使自己的**更利於重用、更利於被人理解、可靠性更***。
不同的情況下需要用什麼樣的模式，如何實現這些模式，在各類著作中已經介紹的相當清晰了，但是關於設計模式實現的時機，卻提的比較少。
過度設計是指**的靈活性和複雜性超出所需。如果我們在設計初期，就實現各類模式，進行完整的規劃，隨著需求的逐步修改，很可能出現大量的不再需要的設計，這完全不符合敏捷開發的思想。
設計不足是指不良的開發方式導致後期難以維護。顯然，如果我們不進行任何規劃，隨意的新增功能，就會使專案越來越混亂，以至於最後為了增加一些功能，不得不推倒重新設計。
不進行合理的規劃是絕對不行的，而在初期就進行規劃代價又太大，好像沒有了解決的辦法。但是，當你聯想起tdd（測試驅動開發）的基本步驟，就會發現大部分的模式實現其實在重構過程中就能完成。
1.針對需求，編寫測試用例；
2.編寫權宜**，使測試能夠完全通過；
3.重構**。
重構使**更清晰、更易於維護，同時不需要初期花費大量的時間進行詳細的規劃。
模式痴迷是指某人對模式過於依賴，以至於無法不在**中實現模式。初學者為了練習所學的設計模式，會出現大量並不恰當的模式實現。熟練掌握各類設計模式的開發者，更也有可能出現這種依賴。在進行一項設計時，首先想到的就是它適用於哪種模式，甚至忘記了switch可能更簡單、更易於理解。
在重構的過程中，什麼情況下應該使用設計模式？應該用哪種模式？
**壞味
重構方法
重複**
形成template method
用factory method引入多型建立
鏈建構函式
用composite替換一/多之分
提取composite
通過adapter統一介面
引入null object
方法過長
組合方法
將聚集操作搬移到collecting paramter
用command替換條件排程
將聚集操作搬移到visitor
用strategy替換條件邏輯
條件邏輯太複雜
用strategy替換條件邏輯
將裝飾功能搬移到decorator
用state替換狀態改變語句
引入null object
基本型別迷戀
用類替換型別**
用state替換條件改變語句
用strategy替換條件邏輯
用composite替換隱函樹
用interpreter替換隱式語言
將裝飾功能搬移到decorator
用builder封裝composite
不恰當的暴露
用factory封裝類
解決方案蔓延
將建立知識搬移到factory
相似功能的類
通過apapter統一介面
冗贅類內斂singleton
類過大用command替換條件排程語句
用state替換狀態改變語句
用interpreter替換隱式語言
分支語句
用command替換條件排程程式
將聚集操作搬移到visitor
組合**
用interpreter替換隱式語句
怪異解決方案
通過adapter統一介面
1...-1
-1-1
-1-1
-1-1
...-1
敏捷開發模式
是一種從1990年代開始逐漸引起廣泛關注的一些新型 軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱 理念 過程 術語都不盡相同，相對於 非敏捷 更強調程式設計師團隊與業務專家之間的緊密協作 面對面的溝通 認為比書面的文件更有效 頻繁交付新的軟體版本 緊湊而自我組織型的團隊 ...
《敏捷軟體開發 原則 模式與實踐》 第五章 重構
本章的主要講的是重構，但是僅僅給出了乙個重構的例子以及簡略說明了一些重構的方法。重構的知識我認為對於開發人員還是很有必要去單獨去找一本書仔細去學習的。這裡只大略講一下本章中提到的一些知識點。本章站在第一視角，對乙個素數產生的程式進行了重構。看到書中最原始的程式版本，我不禁冒出了一句 什麼鬼？程式中竟...
重構與模式
設計模式 和 重構 之後又一里程碑式著作，凝聚眾多業界專家經驗與領悟，幫你打通重構與模式任督二脈。1994年，設計模式 為我們帶來了常見設計問題的經典解決方案，從而改變了整個物件導向開發的面貌。1999年，重構 為我們帶來了一種改進 的高效過程，從而徹底改變了物件導向設計的方式。現在，在眾所期盼之中...