【大話設計模式】全域性把握篇
告別了UML後，就迎來了大話設計模式，在之前看到師姐經常抱著這本書穿梭在511和501和四樓，師姐對這本書的重視可以用四個字來形容：如視珍寶，原來還比較好奇師姐總是拿著小人兒書幹嘛啊，現在終於明白了，我小心翼翼的翻開設計模式，認認真真的看著每一個設計模式。不乏也讀懂了點什麼，現在和大家分享一下。
《簡介》
設計模式不是一本小人書兒，不是一本程式書，而是通過故事講述成熟如何設計的方法集
設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使程式碼編制真正工程化；設計模式是軟體工程的基石脈絡，如同大廈的結構一樣。（百度上面的解釋）
《本書定位》
讓我們站在巨人的肩膀，展翅翱翔
《本書特色》
1、重視過程
2、貼近生活
《為何學習設計模式》
如果系統當初設計的時候沒有考慮某些需求的變化，或者隨著需求的累加，系統越來越臃腫，導致隨便修改一處都可能造成不可預料的後果，或者是我本來可以修改下配置檔案或者改一處程式碼就可以解決的事情，結果需要修改N處程式碼才可以達到我們想要的目的。
這樣設計模式就顯的尤為重要
《設計模式的好處》
在學習設計模式過程中，你會被那些程式設計大師們進行偉大的技術思想洗禮，不斷增加自己面向物件的深入理解，從而更好的把這種思想發揚光大。通過這些模式讓你找到“封裝變化
如果數學是思維的體操，那設計模式，就是面向物件程式設計思維的體操
《指導原則：七大原則》
1、單一職責原則（Single Responsibility Principle）
定義：不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責，應該僅有一個引起它變化的原因優點：1.可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
2.提高類的可讀性，提高系統的可維護性；
3.變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。
2、開閉原則（Open Close Principle）
定義：一個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉。分析：（1）開放-封閉原則的意思就是說，你設計的時候，時刻要考慮，儘量讓這個類是足夠好，寫好了就不要去修改了，如果新需求來，我們增加一些類就完事了，原來的程式碼能不動則不動。這個原則有兩個特性，一個是說“對於擴充套件是開放的”，另一個是說“對於更改是封閉的”。面對需求，對程式的改動是通過增加新程式碼進行的，而不是更改現有的程式碼。這就是“開放-封閉原則”的精神所在
（2）實現開閉原則的關鍵就是抽象化 :在"開-閉"原則中,不允許修改的是抽象的類或者介面,允許擴充套件的是具體的實現類,抽象類和介面在"開-閉"原則中扮演著極其重要的角色..即要預知可能變化的需求.又預見所有可能已知的擴充套件..所以在這裡"抽象化"是關鍵!
（3)可變性的封閉原則:找到系統的可變因素,將它封裝起來. 這是對"開-閉"原則最好的實現. 不要把你的可變因素放在多個類中,或者散落在程式的各個角落. 你應該將可變的因素,封套起來..並且切忌不要把所用的可變因素封套在一起. 最好的解決辦法是,分塊封套你的可變因素!避免超大類,超長類,超長方法的出現!!給你的程式增加藝術氣息,將程式藝術化是我們的目標!
3、里氏代換原則( Liskov Substitution Principle ,LSP )
定義：任何基類可以出現的地方,子類也可以出現
分析：1）講的是基類和子類的關係，只有這種關係存在時，里氏代換原則才存在。正方形是長方形是理解里氏代換原則的經典例子。
2）里氏代換原則可以通俗表述為：在軟體中如果能夠使用基類物件，那麼一定能夠使用其子類物件。把基類都替換成它的子類，程式將不會產生任何錯誤和異常，反過來則不成立，如果一個軟體實體使用的是一個子類的話，那麼它不一定能夠使用基類。
3）里氏代換原則是實現開閉原則的重要方式之一，由於使用基類物件的地方都可以使用子類物件，因此在程式中儘量使用基類型別來對物件進行定義，而在執行時再確定其子類型別，用子類物件來替換父類物件。
4、依賴倒轉原則( Dependence Inversion Principle ,DIP )
定義：要依賴抽象,而不要依賴具體的實現.
高層模組不應該依賴低層模組，它們都應該依賴抽象。抽象不應該依賴於細節，細節應該依賴於抽象。簡單的說，依賴倒置原則要求客戶端依賴於抽象耦合。原則表述：
1）抽象不應當依賴於細節；細節應當依賴於抽象；
2）要針對介面程式設計，不針對實現程式設計。
分析：1）如果說開閉原則是面向物件設計的目標,依賴倒轉原則是到達面向設計"開閉"原則的手段..如果要達到最好的"開閉"原則,就要儘量的遵守依賴倒轉原則. 可以說依賴倒轉原則是對"抽象化"的最好規範! 我個人感覺,依賴倒轉原則也是里氏代換原則的補充..你理解了里氏代換原則,再來理解依賴倒轉原則應該是很容易的。
2）依賴倒轉原則的常用實現方式之一是在程式碼中使用抽象類，而將具體類放在配置檔案中。
3）類之間的耦合：零耦合關係，具體耦合關係，抽象耦合關係。依賴倒轉原則要求客戶端依賴於抽象耦合，以抽象方式耦合是依賴倒轉原則的關鍵。
5、合成/聚合複用原則(Composite/Aggregate ReusePrinciple ，CARP)
定義：要儘量使用物件組合,而不是繼承關係達到軟體複用的目的
6、迪米特法則(Law of Demeter，LoD
定義：系統中的類,儘量不要與其他類互相作用,減少類之間的耦合度
又叫最少知識原則（Least Knowledge Principle或簡寫為LKP）幾種形式定義：
(1) 不要和“陌生人”說話。英文定義為：Don't talk to strangers.
(2) 只與你的直接朋友通訊。英文定義為：Talk only to your immediatefriends.
(3) 每一個軟體單位對其他的單位都只有最少的知識，而且侷限於那些與本單位密切相關的軟體單位。
簡單地說，也就是，一個物件應當對其它物件有儘可能少的瞭解。一個類應該對自己需要耦合或呼叫的類知道得最少，你（被耦合或呼叫的類）的內部是如何複雜都和我沒關係，那是你的事情，我就知道你提供的public方法，我就呼叫這麼多，其他的一概不關心。
7、介面隔離法則(Interface Segregation Principle，ISL）
定義：客戶端不應該依賴那些它不需要的介面。
另一種定義方法：一旦一個介面太大，則需要將它分割成一些更細小的介面，使用該介面的客戶端僅需知道與之相關的方法即可。
1）介面隔離原則是指使用多個專門的介面，而不使用單一的總介面。每一個介面應該承擔一種相對獨立的角色，不多不少，不幹不該乾的事，該乾的事都要幹。
•(1)一個介面就只代表一個角色，每個角色都有它特定的一個介面，此時這個原則可以叫做“角色隔離原則”。
•(2)介面僅僅提供客戶端需要的行為，即所需的方法，客戶端不需要的行為則隱藏起來，應當為客戶端提供儘可能小的單獨的介面，而不要提供大的總介面。
2）使用介面隔離原則拆分介面時，首先必須滿足單一職責原則，將一組相關的操作定義在一個介面中，且在滿足高內聚的前提下，介面中的方法越少越好。
3）可以在進行系統設計時採用定製服務的方式，即為不同的客戶端提供寬窄不同的介面，只提供使用者需要的行為，而隱藏使用者不需要的行為。
《二十三個設計模式》
1、Abstract Factory（抽象工廠模式）
提供一個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類。
2、Adapter（介面卡模式）
將一個類的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。
3、Bridge（橋接模式）
將抽象部分與它的實現部分分離，使它們都可以獨立地變化。
4、Builder（建造者模式）
將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。
5、Chain of Responsibility（職責鏈模式）
為解除請求的傳送者和接收者之間耦合，而使多個物件都有機會處理這個請求。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個物件處理它。
6、Command（命令模式）
將一個請求封裝為一個物件，從而使你可用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援可取消的操作。
7、Composite（組合模式）
將物件組合成樹形結構以表示“部分-整體”的層次結構。它使得客戶對單個物件和複合物件的使用具有一致性。
8、Decorator（裝飾模式）
動態地給一個物件新增一些額外的職責。就擴充套件功能而言， 它比生成子類方式更為靈活。
9、Facade（外觀模式）
為子系統中的一組介面提供一個一致的介面，Facade模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。
10、Factory Method（工廠模式）
定義一個用於建立物件的介面，讓子類決定將哪一個類例項化。Factory Method使一個類的例項化延遲到其子類。
11、Flyweight（享元模式）
運用共享技術有效地支援大量細粒度的物件。
12、Interpreter（解析器模式）
給定一個語言, 定義它的文法的一種表示，並定義一個直譯器, 該直譯器使用該表示來解釋語言中的句子。
13、Iterator（迭代器模式）
提供一種方法順序訪問一個聚合物件中各個元素，而又不需暴露該物件的內部表示。
14、Mediator（中介模式）
用一箇中介物件來封裝一系列的物件互動。中介者使各物件不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。
15、Memento（備忘錄模式）
在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到儲存的狀態。
16、Observer（觀察者模式）
定義物件間的一種一對多的依賴關係,以便當一個物件的狀態發生改變時,所有依賴於它的物件都得到通知並自動重新整理。
17、Prototype（原型模式）
原型例項指定建立物件的種類，並且通過拷貝這個原型來建立新的物件。
18、Proxy（代理模式）
為其他物件提供一個代理以控制對這個物件的訪問。
19、Singleton（單例模式）
保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。
20、State（狀態模式）
允許一個物件在其內部狀態改變時改變它的行為。物件看起來似乎修改了它所屬的類。
21、Strategy（策略模式）
定義一系列的演算法,把它們一個個封裝起來, 並且使它們可相互替換。本模式使得演算法的變化可獨立於使用它的客戶。
22、Template Method（模板方法模式）
定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。
23、Visitor（訪問者模式）
表示一個作用於某物件結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。
《二十三個設計模式的關係》
小結：
首先對設計模式有個全域性觀的把握，在根據三遍讀書法慢慢詳讀，深入理解大師們的思想。同時通過敲例子與大師擦出精神的火花。這樣學習的效果會非常的好，接下來我會寫一系列的部落格，也希望能多和我討論。接下來就是逐個擊破了。。