看完了，就全忘了，不總結就等於沒看！所以大概的總結了。
大話設計模式
大話設計模式中將近三十種模式，是將我們原來的代碼框架思路轉變成另一種思路。代碼和生活是一樣的，當我們發現重複的去做一件事情的時候就會思考是否會有捷徑有效率的完成，而在程序中當大量重複的代碼出現時，我們就自然想到類、抽象、接口，而又是如何讓每一類獨立性更強，如何達到最佳的分類效果，這就要靠我們在學習中發現和探索。而設計模式是我們思路的指導，讓我們對面向對象編程更加深刻的認識。而最終的目的是我們設計出易維護、易擴展、易複用、靈活性好的程序。
簡單工廠模式---計算器
在該模式中就是把我們平時寫計算器的代碼進行模塊化，是從宏觀上設計，將原來我們只值注重在主函數中寫代碼轉到把大體相同的事物抽象爲類。抽象出運算類抽象類，並且加法類、減法類、乘法類、除法類繼承該抽象類。爲了避免更多的重複操作，考慮用一個單獨的類來做這個創造實例的過程，從而增加了運算工廠類，從而使客戶端代碼進一步簡潔。
策略模式---商場收銀
在這個模式告訴我們代碼不但要實現單一的功能，而是要想到這個程序的複用，和擴展性，代碼是否複雜和重複的太多，軟件的健壯性和效率問題。
一個簡單的根據單價和數量來計算總的錢數。在這裏提出的是是增加打折之後怎樣去實現。
用我們開始所學的簡單工廠模式，是把打折方式分爲類，並且繼承策略這個超類。而在具體的策略類中爲了傳入具體的策略對象另一方面是爲了調用策略中的方法。這樣只讓客戶端識別了一個cashContext類，而用簡單工廠要識別CashSuper和CashFactory兩個類。
策略模式是一種定義一下列算法，從概念上來看，所有這些算法都是相同的工作，只是實現不同，它可以用相同的方式來調用所有的算法，減少了各種算法類與使用算法類之間的耦合。
單一職責原則---手機拍攝UFO
小菜要拍攝UFO，從而想到攝像機和我們平時使用的手機上帶的攝像頭的不同。單一職責原則：一個類，應該僅有一個引起它變化的原因。軟件設計真正要做的很多，就是發現職責，並把這些職責相互分離。
開放封閉原則---考研和工作
從小菜考研和工作要做到同時準備來說，提出了開放封閉式原則，就是說軟件實體（類、模塊、函數）等應該可以擴展，但是不可以修改。對於擴展是開放的，對於更改是封閉的。要多擴展少修改，就像開始所學的簡單工廠模式一樣，在原來的代碼基礎上是通過增加代碼（類）來進行的，而不是通過改現有的代碼。
依賴倒轉原則---修電腦和收音機
在修計算機主機的時候發現各個插槽接口是獨立的接口，並且對與有的插槽可以擴展，例如內存不夠可以擴展，硬盤不夠可以使用可移動硬盤，所以總結出抽線不應該依賴於細節，細節應該依賴於抽象，要針對接口編程，不要針對實現編程。
里氏代換原則---依賴了接口和抽象類就不怕了
子類型必須能夠替換其父類型。只有當子類可以替換掉父類，軟件單位的更能不受影響，父類才能真正的被複用，而子類也能夠在父類的基礎上增加新的行爲。
裝飾模式---衣服種類和要打扮的人分離
可以動態的實現“穿衣服”，爲已有的功能動態的添加更多的功能。
代理模式---戴勵代卓賈易追嬌嬌
把送禮物抽象出接口，讓代理和實際的追求者來實現接口中的方法，而代理和追求者之間是相互依賴的關係。
工廠方法模式---雷鋒工廠
工廠方法模式是簡單工廠模式的抽象和擴展。工廠方法模式是由客戶端來決定實例化哪一個工廠實現運算類。在簡單工廠類中要增加功能是是改動的是工廠類，而在工廠方法模式要改的就是客戶端了，從客戶端中實例化工廠類來進行調用。
原型模式---簡歷複印（淺複製）
原型模型是從一個對象再創建另一個可定製的對象，而且不需要知道任何的創建細節。。Net在System命名空間中提供了ICIoneable接口，繼承這個接口來實現的複製，這個接口中的方法Clone（）。
模版方法模式---把試題和答案分離
模版方法通常是把不變的行爲搬移到超類中，去除子類中的重複代碼來體現優勢。
迪米特法則---辦事找部門（找低層次的模塊）
如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接相互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發。
外觀模式---對基金的操作和股票的類型分離
增加外觀類來減少接口，使客戶端簡單。
建造者模式---建造小人
把構造小人和表示小人分開。
觀察者模式---老闆和祕書通知員工
定一個了通知者和被通知者接口，具體的通知者和被通知者來分別實現這個接口，在抽象的通知者接口中定義抽象的方法這樣以便可以動態的添加和刪除被通知者。當一個對象的改變需要同事改變其他對象的時候應該考慮到使用觀察者模式。
抽象工廠模式---數據庫的更換
與工廠模式不同的是，的業務邏輯層只有一個類，而抽象工廠模式又添加了IDepartment的抽象接口和類。簡單工廠模式、工廠模式和抽象工廠模式，三個模式比較來就好理解了。
狀態模式---把不同的工作狀態分離出來
當一個對象的內在狀態改變時，允許改變其行爲，這個對象看起來像是改變了其類。感覺狀態模式和前面的策略模式有異曲同工之妙。在這裏面用的是把Context類作爲了狀態類state的抽象方法來使用的，並在具體的狀態類中把下一狀態賦值了。
狀態模式的好處是將與特定狀態相關的行爲局部化，並且將不同的行爲分割開來。
適配器模式---在NBA需要翻譯
適配器模式，將一個類的接口轉換成爲客戶希望的另外的一個接口。就是在翻譯者類中實例化姚明，並在方法中進行“翻譯”。
備忘錄模式---遊戲進度
在不破壞封裝型的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以後就可以對這個狀態進行恢復了。也就是在備忘類中傳遞一個發起人類的state字符串。
組合模式---分公司和部門
將對象組合成樹形結構來表示“整體和部分”的關係。聲明一個抽象的Componet類管理子部件和葉子部件，該抽象類中定義增加、移除和顯示的抽象方法，葉子類和枝幹類分別繼承該抽象類。
迭代器模式---售票員遍歷車上所有的人
定義了一個迭代器抽象類、要迭代的抽象類、具體的迭代器、具體的要迭代的類。在具體的迭代器類中聲明要迭代的類，在具體的聚集類中實例化一個具體的要迭代的類，並將當前的聚集類傳遞到具體的迭代器的類中，在迭代器的類中作爲構造函數進行初始化。
單例模式---類的計劃生育
是通過的改變類的構造方法來實習的，因爲對於類的構造方法，如果不聲明類的構造方法，系統則默認無參的構造方法，如果顯示的定義了，默認的構造方法就失效了。
單例模式是保證一個類僅有一個實例，並且提供一個訪問它的全局訪問點，把默認的構造方法設置爲私有的，通過定義該類中的一個方法來進行實例化，再在客戶端判斷是否重複實例化。
橋接模式---不同手機對軟件的兼容問題
合成聚合原則：是儘量使用合成/聚合，儘量不要使用類的繼承。橋接模式就將抽象部分和它的實現分離，使他們都可以獨立的變化。定義手機品牌和手機軟件兩個抽象類且他們之間是聚合的關係，具體手機品牌類和具體的遊戲類再去繼承他們。
命令模式---烤肉請求烤肉師傅實現
抽象命令類，在該類中實例化一個具體的烤肉者和一個抽象的命令。具體的命令類在繼承該類的時候複寫父類中的方法，從而實現了服務員通知烤肉者，而在Waiter類中聲明一個私有命令類，和兩個方法。當考慮到在點菜的過程中有的客戶會取消或是更換菜品，所以近一步更改了Waiter類，並在該類中定一個了command數組，通過數組的add方法和Remove來進行對增加和減少訂單。
職責鏈模式---權限問題解決
將對象連接成一個鏈，判斷權限，直到有能處理的對象處理它。就是在定一個每個具體的處理類的時候首先是判斷這個請求的權限，如果有權限則執行，如果沒有權限則轉到下一個高級別的。
中介者模式---聯合國安理會要知道所有的國家
主要是依賴聯合國安理會這個類，通過這個類來實現國家之間的通信，而不是各國之間直接通信，雖然實現了各個國家的獨立，但是增加了安理會這個中介類的負擔。
享元模式---通過判斷來分享
通過網站工廠類來判斷網站類的對象是否被實例化了，實例化則直接返回，沒有實例化則實例化再返回。
解釋器模式---解釋
解釋器固定，Context來傳入，傳入後判斷。
訪問者模式---狀態和人類分開
把男人和女人成功和失敗的狀態分開，並且增加了對象結構類，來增加具體的男人類和女人類。性別穩定，狀態穩定，人的個數可以增加，在狀態中傳遞一個具體的人類來顯示狀態。
其實各個模式的本質是一致的，且模式就像算法？還是說是圖紙上的框架呢？模式也不是絕對的，不同的需求適合不同的模式，找個平衡就好吧，還在在具體的蓋房子過程中才會體會到吧。