讀後感：陸續花了三周時間，閱讀了《大話設計模式》的電子書版本。在此之前也閱讀過其它講解設計模式的書，但是往往過於抽象，舉例複雜，讀起來很是吃力，都堅持不下來；閱讀這本書比較輕鬆。
本書的優點：就是淺顯易懂，適合於入門者；
本書的缺點：就是有些地方講解並不深入全面；並沒有給出用.net實現時，如何實現更優；在c#類庫中用到了那些模式；舉的小例子有時候是便於理解，但是實際工作中，學習者並不能真正會使用，可以列舉實際用到企業庫，petshop等等，實際的專案中是如何使用設計模式的；
《大話設計模式》學習筆記如下
技巧與原理：
如果想成為一名更優秀的軟體設計師，了解優秀軟體設計的演變過程比學習優秀設計本身更有價值，因為設計的演變過程中蘊藏著大智慧型。——《重構與模式》
軟體開發，要求應用程式：可維護、可擴充套件、可復用、靈活性好。
面對物件程式設計，可以通過封裝、繼承和多型把程式的耦合度降低；用設計
模式使程式更加的靈活。
第一章：簡單工廠模式
簡單工廠模式的最大優點在於工廠類中包含了必要的邏輯判斷，根據客戶端的選擇條件動態的例項化相關的類，對於客戶端來說，去除了與具體產品的依賴。
第二章：策略模式
定義：策略模式（strategy）:它定義了演算法家族，分別封裝起來，讓他們之間可以互相替換，此模式讓演算法的變化，不會影響到使用演算法的客戶。
優點：策略模式使一種定義一系列演算法的方法，從概念上來看，所有這些演算法完成 的都是相同的工作，只是實現不同，它可以以相同的方式呼叫所有的演算法，減少了各種演算法類與使用演算法類之間的耦合。
策略模式的strategy類層次為contex定義了一系列的可供重用的演算法或行為。繼承有助於析取出這些演算法中的公共功能。
策略模式的優點是簡化了單元測試，因為每個演算法都有自己的類，可以通過自己的介面單獨測試。
當不同的行為堆砌在乙個類中時，就很難避免使用條件語句來選擇合適的行為。將這些行為封裝在乙個乙個獨立的strategy類中，可以在使用這些行為的類中消除條件語句。
策略模式就是用來分封裝演算法的，但在實踐中，我們發現可以用它來封裝計畫任何型別的規則，只要在分析過程中聽到在不同時間應用不同的業務規則，就可以考慮使用策略模式處理這種變化的可能性。
在基本的策略模式中，選擇所用具體實現的職責由客戶端物件承擔，並轉給策略模式的contex物件。
第三章：單一職責原則
單一職責原則（srp）：就乙個類而言，應當僅有乙個引起他變化的原因。
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會消弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意向不到的破壞。
軟體設計真正要做的許多內容，就是發現職責並把這些職責分離。如果你能夠想到多於乙個的動機去改變這乙個類，那麼這個類就具有多於乙個的職責。
第四章：開放-封閉原則
開放-封閉原則：軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可以修改。
特徵：（1）對於擴充套件是開放的；（2）對於更改時封閉的。
無論模組是多麼的『封閉』，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。
等到變化發生時立即採取行動。
在我們最初編寫**時，假設變化不會發生。當變化發生時，我們就建立抽象來隔離一會發生的同類變化。
面對需要，對程式的改動是通過增加新**進行的，而不是更改現有的**。
我們希望的是在開發工作展開不久就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要建立**的抽象就越困難。
開發-封閉原則是物件導向設計的核心所在。遵循這個原則可言帶來物件導向技術所聲稱的巨大好處，也就是可維護、可擴充套件、可復用、靈活性好。開發人員應當僅對程式中呈現出頻繁變化的那些部門做出抽象，然而，對於應用程式中的每個部分都可以地抽象同樣不是乙個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
第五章：依賴倒轉原則
依賴倒轉原則（或依賴倒置原則）：
a 高層模組不應當依賴低層模組。兩個都應該依賴抽象。
b 抽象不應該依賴細節。細節應該依賴抽象。
黎克特制轉換原則（lsp）：子型別必須能夠替換掉他們的父型別。
乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且察覺不出父類物件和子類物件的區別。也就是說，在軟體裡面，把父類都替換成它的子類，程式的姓名沒有變化。
只有當子類可以替換掉父類，軟體單位的功能不受影響時，父類才真正被復用，而子類也能夠在父類的基礎上增加新的行為。
由於子型別的可替換性才使得使用父類型別的模組在無需修改的情況下酒可以擴充套件。
依賴倒轉其實可以說是物件導向設計的標誌，用哪種語言來編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有依賴的關係都是終止於抽象類火災介面，那就是物件導向的設計，反之那就是過程化的設計了。
第六章：裝飾模式
裝飾模式（decorator），動態地給乙個物件新增一些額外的職責，就增加功能來說，裝飾模式比生產子類更為靈活。
每個裝飾物件的實現就和如果使用這個物件分離開了，每個裝飾物件只關係自己的工鞥，不需要關係如何被新增到物件鏈當中。
裝飾模式使為已有功能動態地新增更多功能的一種方式。當系統需要新功能的時候，是向舊的類中新增新的**。這些新新增的**通常裝飾了原有類的核心職責或主要行為。在主類中加入了新的字段，新的方法和新的邏輯，從而增加了主類的複雜度。而這些新加入的東西僅僅是為了滿足一些只在某種特定情況下才會執行的特殊行為的需要。裝飾模式卻提供了乙個非常好的解決方案，它把每個要裝飾的功能放在單獨的類中，並讓這個類包裝它所要裝飾的物件，
因此當需要執行特殊行為時，客戶**就可以在執行時根據需要有選擇地，按順序地使用裝飾功能包裝物件了。
優點：（1）把類中的裝飾功能從類中搬移去除，這樣可以簡化原有的類。
（2）有效地把類的核心職責和裝飾功能區分開了。而且可以去除相關類中重複的裝飾邏輯。
第七章：**模式
**模式（proxy）：為其它物件提供依照那個**以控制這個物件的訪問。
**分類：
（1）遠端**，也就是為乙個物件在不同的位址空間提供區域性代表。這樣可以隱藏乙個物件存在於不同的位址空間的事實。
（2）虛擬**，是根據需要建立開銷很大的物件。通過它來存放例項化需要很長時間的真實物件。
（3）安全**，用來控制真實物件訪問時的許可權。
（4）智慧型指引，是指當呼叫真實的物件時，**處理另外一些事。
第八章：工廠方法模式
簡單工廠模式的最大優點在於工廠類中包含了必要的邏輯判斷，根據客戶端的選擇條件動態的例項化相關的類，對於客戶端來說，去除了與具體產品的依賴。
工廠方法模式（factory method），定義乙個用於建立物件的介面，讓子類決定例項化哪乙個類。工廠方法使乙個類的例項化延遲到其子類。
工廠方法克服了簡單工廠違背開放-封閉原則的缺點，又保持封裝物件建立過程的優點。
工廠方法的缺點是由於每增加乙個產品，就需要加乙個產品工廠的類，增加了額外的開發量。
缺點克服：可以使用.net中的反射。
第九章：原型模式
原型模式（prototype），用原型例項指定建立物件的種類，並且通過拷貝這些原型建立新的物件。
原型模式其實就是從乙個物件再建立另外乙個可定製的物件，而且不需要指定任何建立的細節。
第十章：模板方法模式
模板方法模式（template method）：定義乙個操作中的演算法骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變乙個演算法的結構及可重用該演算法的某些特定步驟。
模板方法模式是通過把不變行為搬遷到超類，去除子類中的重複**來體現它的優勢。
當不變的和可變的行為在方法的子類實現中混合在一起的時候，不變的新聞就會在子類中重複出現。我們通過模板方法模式把這些行為搬遷到單一的地方，這樣就幫助子類擺脫重複的不變的行為的糾纏。
設計模式1
facade模式 當你需要使用乙個很複雜的系統，你作為乙個使用者，當然希望使用起來越簡單越好，最好是乙個概念上的功能只需要呼叫乙個函式介面。這時候向你提供系統的人就要考慮使用facade模式了。通過這種模式改進後，系統提供者把系統的對外使用的複雜度降低了，使用者就可以很簡單的使用系統了。舉例來說，在...
設計模式 1
oo 基礎 1 抽象 2 封裝 3 多型 4 繼承 oo原則 1 封裝變化 2 多用組合，少用繼承 3 針對介面程式設計，不針對實現程式設計 4 為互動物件之間的松耦合設計而努力 5 類應該對擴充套件開放，對修改關閉 6 依賴抽象，不要依賴具體類 7 只和朋友交談 8 別找我，我會找你 9 類應該只...
設計模式（1）
單例模式 保證為乙個類只生成唯一的例項物件。也就是說在整個程式空間中該類只存在乙個例項物件。include using namespace std class usermanager public static usermanager getinstance private static userm...