設計模式是一些前人對物件導向程式設計方式進行總結而得出的一些巧妙的程式設計技巧，通過學習《大話設計模式》這本書，一方面鞏固了對c#的學習，還有一方面進一步了解了物件導向程式設計技巧。模式有非常多種。各有優缺點。可是還要根據實際情況而定。並非不論什麼情況下某個模式都適用的，所以某個模式。指的是在某個詳細情況下用這樣的方法去程式設計實現。能夠降低系統的開銷、優化程式**、提高效率等等。
以下則是我學習這本書的時候。每敲完乙個例項之後。都用自己能理解的話對這個模式的理解的記錄，既不官方，也不太通俗易懂，至少自己能看懂而已，有些還弄的不太懂，希望掠過的大鳥可以指導指導。當中也有一部分是對物件導向裡面的一些元素的理解。也都請多多批評不吝賜教。順序不太對，還有的是缺少了非常多模式，這裡是由於當時敲完之後沒進行及時的總結。然後就忘了，以後有機會再補吧！
首先創造乙個類a，類中包含各種私有屬性和公有方法，可是新增了乙個memberwiseclone()方法（該方法是類裡面預設自帶的乙個特殊的方法）。當你用a例項化乙個物件a之後，再呼叫a的memberwiseclone()方法賦給用a例項化的還有乙個物件b，則b就是a的乙個虛擬複製品，當b中使用某個方法傳入資料時，那麼這個資料就會覆蓋原來與a同樣的資料。達到了複製物件然後對物件的改動卻不影響到其它的資料的作用。
有多個子類都有相似的方法，使用的時候都須要共同呼叫。則能夠建立乙個類用以例項化這些子類，並分類建立呼叫這些子類的方法，這樣就能夠僅僅呼叫新類的某個方法（包括子類多個方法）來統一呼叫多個子類的方法。能夠降低類間的耦合度
對複雜類抽象出父類。使得子類去實現這些複雜的細節，然後建立乙個指揮者類，把父類放進去，與指揮者形成組合關係，實現的時候子類當作引數放進指揮者類中就可例項化出想要的物件。
抽象類：
為什麼會有抽象類呢？由於假設沒有抽象類的話。詳細類假設太多。而且他們有非常多共性，那麼要建立這麼多類，就要多寫非常多反覆的**。
有乙個中介類（聯合國）。他裡面有各個終端類（國家）作為資料成員，建立終端類之後，各個終端類要傳送訊息給其它終端類，首先經過中介類的推斷是發給誰，然後中介類負責找到接受者，然後傳遞訊息。
這樣就減輕了終端類的負擔（尋找類的負擔）。
把不變的。但在實現裡須要用到的**放到父類中。這樣子類在實現的時候僅僅須要呼叫父類方法和詳細實現即可。假設有非常多子類，則都是通過呼叫父類。所以實現了**的復用。
創造出乙個類，不應該直接用來例項化。而是依賴於介面去實現，而假設要實現的類非常多或考慮到擴充套件，則應該建立乙個介面工廠，然後繼承這個介面工廠的工廠作為實現這些類的介面，再通過這些類的介面去實現這些類從而產生物件。（太繞了，我有點難以接受）
依賴倒轉原則：
類依賴於介面實現，介面不應依賴於類，這樣無論你新增還是改動，都不會影響到其它類了。
反射-抽象工廠的資料訪問程式。。。沒懂
假設物件能夠處在非常多種狀態，那麼能夠將每乙個狀態寫作乙個類，並初始化狀態，按線性鏈結的方式將全部狀態鏈結起來。通過初始狀態推斷是否為初始。假設不是則轉入下乙個狀態的推斷。
某物件依賴於介面，後來擴充套件別的類之後卻無法使用這個介面去訪問那個物件，所以再寫乙個介面來對接原來的介面。並使這個新街口能適應擴充套件出來的類（印象不太深，可能不正確）。
假設某個物件a經歷某些事件之後，其資料成員發生變化。假設想恢復到原來的狀態，能夠提前建立乙個物件b用來儲存這些資料成員，可是又不要直接進行賦值。還以能夠再建立乙個物件c用來作為建立物件b的工廠類。這樣就能夠讓物件a通過物件c間接地將資料儲存到物件b 裡面。
建立乙個抽象類，子類a和b繼承抽象類，可是僅僅有a真正的去實現父類的方法。並可將屬於父類的子類裝進乙個類似陣列的容器裡面。然後我就不知道為什麼要將這些子類放進去了！
讓自己給自己提供方法例項化自己。並保證僅僅能例項化乙個，並把建構函式寫成私有，僅僅能依靠全域性變數的呼叫來呼叫該方法以實現例項化該類。
假設有兩個佔主體地位的比較頂層的父類，他們當中乙個派生出來的類假設一層一層的繼承下去。然後由於還有乙個基類的不同。又要適應這還有乙個類，那麼這樣就會導致要產生非常多類，並形成複雜的關係。
這個時候則能夠讓這兩個類形成聚合關係，這時候僅僅須要對乙個類下功夫（這個類的功能包含將還有乙個類當作引數傳遞下去），就能夠讓功能就像是在適應乙個類就能夠了。這兩個類之間用聚合符號鏈結起來像一座橋，所以叫橋接模式。
明白的分工，顧客僅僅管下單子。無論肉串怎麼做、還有沒有，服務員僅僅管推斷還有沒有肉串。有就提交，以及滿足顧客的服務，廚子僅僅管做菜。然後顧客通過提交詳細的肉串給服務員。服務員再命令廚子去做，這就是命令模式。能夠在命令類裡面做個儲存命令的陣列，然後就能夠滿足客戶新增和撤銷命令了。
有不同級別的類，他們所能處理的請求也因級別而異，當接收到請求時，假設不能處理，則把請求傳遞給自己的上級（要有乙個能設定自己上級的方法）。
設計模式總結
http www.chenjiliang.com article view.aspx?articleid 6708 比較 設計模式 常用程度 適用層次 引入時機 結構複雜度 abstract factory 比較常用 應用級設計時 比較複雜 builder 一般 級 編碼時一般 factory me...
設計模式總結
模式相關的描述 裝飾者 包裝乙個物件，以提供新的行為 狀態 封閉了基於狀態的行為，並使用委託在行為之間切換 迭代器 在物件的集合之間遊走，而不暴露集合的實現 外觀 簡化一群類的介面 策略 封閉可以互換的行為，並使用委託來決定要使用哪乙個 包裝物件，以控制對此物件的訪問 工廠方法 由子類來決定要建立的...
設計模式總結
這類模式的特質是管理物件的建立過程。通常設計總是以使用工廠方法開始，當設計者發現需要更大的靈活性時，設計會向其它建立型模式演化。工廠方法模式 單例模式 抽象工廠方法模式 建造者模式 原型模式 簡單工廠模式 這類模式從程式的結構上解決模組之間的耦合問題。介面卡模式 裝飾模式 橋接模式 組合模式 享元模...