模式，顧名思義，就是做一種事情的方法歸納，就經驗來說，做什么事情有個好的方法來應對都是可以事半功倍的，在軟件開發中何謂好的模式?
我認為好的模式簡單來說就是保證你應對需求變化的時候不用做更多的代碼修改，而只需要在原有的基礎上進行擴充，也就是所謂的”關閉修改，開放擴展。“
要做到這一點，系統模塊之間的關系絕對不能過于緊密，過于緊密的結果就是，當你一個模塊需要修改，另外一個模塊也需要做相應的修改，這樣，我們軟件開發的成本就加大了，甚至完全適應不了新的需求，這是非常糟糕的。所以，我們在系統架構的設計上一定要做到低耦合(考慮可能的需求變化，任何復雜的設計都是有代價的，在沒有必要做特殊處理的地方都刻意做得很復雜，系統的效率可能會非常低下，這一點在理解了.NET調用虛函數等機制后會有所了解)。假如你滿足了低耦合的條件，一般情況也說明你的系統內聚性比較高(類的責任清晰)。經典的設計模式就是讓我們構建具有此特性系統架構的方法。
今天，我稍微歸納一下幾個設計模式的功能：
1.策略模式：定義了算法族，分別封裝起來，讓他們之間可以互相替換，此模式讓算法的變化獨立于使用算法的客戶。
2.觀察者模式：在對象之間定義一對多的依賴，這樣一來，當一個對象改變狀態，依賴它的對象都會收到通知，并自動更新。
3.動態地將責任附加到對象上。想要擴展功能，裝飾者提供有別于繼承的另一種選擇。
4.抽象工廠模式：提供一個接口，用于創建相關或依賴對象的家族，而不需要明確指定具體類。
5.工廠方法模式：定義了一個創建對象的接口，但由子類決定要實例化的類是哪一個。工廠方法讓類把實例化推遲到子類。
6.單件模式：確保一個類只有一個實例，卻提供全局訪問點。
7.命令模式：將請求封裝成對象，這可以讓你使用不同的請求，隊列，或者日志請求來參數化其他對象。命令模式也可以支持撤銷操作。
8.適配器模式：將一個類的接口轉換成客戶端期望另一個接口。
9.外觀模式：提供另一個統一的接口，用來訪問子系統中的一群接口。外觀定義了一個高層接口，讓子系統更容易使用。
10.模板方法：在一個方法中定義一個算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以在不改變算法結構的情況下，重新定義算法中的某些步驟。
11.迭代器模式：提供一種方法順序訪問一個聚合對象中的各個元素，而又不暴露其內部的表示。
12.組合模式：允許你將對象組成樹形結構來表現“整體/部分”的層次結構。組合能讓客戶以一直的方式處理個別對象和對象組合。
13.狀態模式：允許對象在內部狀態改變時改變它的行為，對象看起來好像修改了它的類。
14.代理模式：為另一個對象提供一個替身或站位符以訪問這個對象。
15.復合模式：復合模式結合兩個或以上的模式，組成一個解決方案，解決一再發生的一般性問題。
?
學習設計模式時間并不長，感覺這門學問在軟件開發中的地位是相當重要的，作為一個初級開發人員，我覺得學習它很有必要的，特別是在看別人的代碼時候，我們可以知其然，更知其所以然，這對程序員的提高是相當有幫助的，呵呵。
)
)
)
