1、什麼是設計模式 算法
設計模式（Design pattern）是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石同樣。項目中合理的運用設計模式能夠完美的解決不少問題，每種模式在如今中都有相應的原理來與之對應，每個模式描述了一個在咱們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被普遍應用的緣由。簡單說：編程
模式：在某些場景下，針對某類問題的某種通用的解決方案。設計模式
場景：項目所在的環境微信
問題：約束條件，項目目標等數據結構
解決方案：通用、可複用的設計，解決約束達到目標。架構
2、設計模式的三個分類 asp.net
建立型模式：對象實例化的模式，建立型模式用於解耦對象的實例化過程。ide
結構型模式：把類或對象結合在一塊兒造成一個更大的結構。函數
行爲型模式：類和對象如何交互，及劃分責任和算法。工具
以下圖所示：
3、各分類中模式的關鍵點
單例模式：某個類只能有一個實例，提供一個全局的訪問點。
簡單工廠：一個工廠類根據傳入的參量決定建立出那一種產品類的實例。
工廠方法：定義一個建立對象的接口，讓子類決定實例化那個類。
抽象工廠：建立相關或依賴對象的家族，而無需明確指定具體類。
建造者模式：封裝一個複雜對象的構建過程，並能夠按步驟構造。
原型模式：經過複製現有的實例來建立新的實例。
適配器模式：將一個類的方法接口轉換成客戶但願的另一個接口。
組合模式：將對象組合成樹形結構以表示「」部分-總體「」的層次結構。
裝飾模式：動態的給對象添加新的功能。
代理模式：爲其餘對象提供一個代理以便控制這個對象的訪問。
亨元（蠅量）模式：經過共享技術來有效的支持大量細粒度的對象。
外觀模式：對外提供一個統一的方法，來訪問子系統中的一羣接口。
橋接模式：將抽象部分和它的實現部分分離，使它們均可以獨立的變化。
模板模式：定義一個算法結構，而將一些步驟延遲到子類實現。
解釋器模式：給定一個語言，定義它的文法的一種表示，並定義一個解釋器。
策略模式：定義一系列算法，把他們封裝起來，而且使它們能夠相互替換。
狀態模式：容許一個對象在其對象內部狀態改變時改變它的行爲。
觀察者模式：對象間的一對多的依賴關係。
備忘錄模式：在不破壞封裝的前提下，保持對象的內部狀態。
中介者模式：用一箇中介對象來封裝一系列的對象交互。
命令模式：將命令請求封裝爲一個對象，使得能夠用不一樣的請求來進行參數化。
訪問者模式：在不改變數據結構的前提下，增長做用於一組對象元素的新功能。
責任鏈模式：將請求的發送者和接收者解耦，使的多個對象都有處理這個請求的機會。
迭代器模式：一種遍歷訪問聚合對象中各個元素的方法，不暴露該對象的內部結構。
4、概說23種設計模式
1.單例模式
單例模式，它的定義就是確保某一個類只有一個實例，而且提供一個全局訪問點。
單例模式具有典型的3個特色：一、只有一個實例。 二、自我實例化。 三、提供全局訪問點。
所以當系統中只須要一個實例對象或者系統中只容許一個公共訪問點，除了這個公共訪問點外，不能經過其餘訪問點訪問該實例時，可使用單例模式。
單例模式的主要優勢就是節約系統資源、提升了系統效率，同時也可以嚴格控制客戶對它的訪問。也許就是由於系統中只有一個實例，這樣就致使了單例類的職責太重，違背了「單一職責原則」，同時也沒有抽象類，因此擴展起來有必定的困難。其UML結構圖很是簡單，就只有一個類，以下圖：
2.工廠方法模式
做爲抽象工廠模式的孿生兄弟，工廠方法模式定義了一個建立對象的接口，但由子類決定要實例化的類是哪個，也就是說工廠方法模式讓實例化推遲到子類。
工廠方法模式很是符合「開閉原則」，當須要增長一個新的產品時，咱們只須要增長一個具體的產品類和與之對應的具體工廠便可，無須修改原有系統。同時在工廠方法模式中用戶只須要知道生產產品的具體工廠便可，無須關係產品的建立過程，甚至連具體的產品類名稱都不須要知道。雖然他很好的符合了「開閉原則」，可是因爲每新增一個新產品時就須要增長兩個類，這樣勢必會致使系統的複雜度增長。其UML結構圖：
3.抽象工廠模式
所謂抽象工廠模式就是提供一個接口，用於建立相關或者依賴對象的家族，而不須要明確指定具體類。他容許客戶端使用抽象的接口來建立一組相關的產品，而不須要關係實際產出的具體產品是什麼。這樣一來，客戶就能夠從具體的產品中被解耦。它的優勢是隔離了具體類的生成，使得客戶端不須要知道什麼被建立了，而缺點就在於新增新的行爲會比較麻煩，由於當添加一個新的產品對象時，須要更加須要更改接口及其下全部子類。其UML結構圖以下：
4.建造者模式
對於建造者模式而已，它主要是將一個複雜對象的構建與表示分離，使得一樣的構建過程能夠建立不一樣的表示。適用於那些產品對象的內部結構比較複雜。
建造者模式將複雜產品的構建過程封裝分解在不一樣的方法中，使得建立過程很是清晰，可以讓咱們更加精確的控制複雜產品對象的建立過程，同時它隔離了複雜產品對象的建立和使用，使得相同的建立過程可以建立不一樣的產品。可是若是某個產品的內部結構過於複雜，將會致使整個系統變得很是龐大，不利於控制，同時若幾個產品之間存在較大的差別，則不適用建造者模式，畢竟這個世界上存在相同點大的兩個產品並非不少，因此它的使用範圍有限。其UML結構圖：
5.原型模式
在咱們應用程序可能有某些對象的結構比較複雜，可是咱們又須要頻繁的使用它們，若是這個時候咱們來不斷的新建這個對象勢必會大大損耗系統內存的，這個時候咱們須要使用原型模式來對這個結構複雜又要頻繁使用的對象進行克隆。因此原型模式就是用原型實例指定建立對象的種類，而且經過複製這些原型建立新的對象。
它主要應用與那些建立新對象的成本過大時。它的主要優勢就是簡化了新對象的建立過程，提升了效率，同時原型模式提供了簡化的建立結構。UML結構圖：
模式結構
原型模式包含以下角色：
Prototype：抽象原型類
ConcretePrototype：具體原型類
Client：客戶類
6.適配器模式
在咱們的應用程序中咱們可能須要將兩個不一樣接口的類來進行通訊，在不修改這兩個的前提下咱們可能會須要某個中間件來完成這個銜接的過程。這個中間件就是適配器。所謂適配器模式就是將一個類的接口，轉換成客戶指望的另外一個接口。它可讓本來兩個不兼容的接口可以無縫完成對接。
做爲中間件的適配器將目標類和適配者解耦，增長了類的透明性和可複用性。
適配器模式包含以下角色：
Target：目標抽象類
Adapter：適配器類
Adaptee：適配者類
Client：客戶類
7.橋接模式
若是說某個系統可以從多個角度來進行分類，且每一種分類均可能會變化，那麼咱們須要作的就是講這多個角度分離出來，使得他們能獨立變化，減小他們之間的耦合，這個分離過程就使用了橋接模式。所謂橋接模式就是講抽象部分和實現部分隔離開來，使得他們可以獨立變化。
橋接模式將繼承關係轉化成關聯關係，封裝了變化，完成了解耦，減小了系統中類的數量，也減小了代碼量。
橋接模式包含以下角色：
Abstraction：抽象類
RefinedAbstraction：擴充抽象類
Implementor：實現類接口
ConcreteImplementor：具體實現類
8.組合模式
組合模式組合多個對象造成樹形結構以表示「總體-部分」的結構層次。它定義瞭如何將容器對象和葉子對象進行遞歸組合，使得客戶在使用的過程當中無須進行區分，能夠對他們進行一致的處理。在使用組合模式中須要注意一點也是組合模式最關鍵的地方：葉子對象和組合對象實現相同的接口。這就是組合模式可以將葉子節點和對象節點進行一致處理的緣由。
雖然組合模式可以清晰地定義分層次的複雜對象，也使得增長新構件也更容易，可是這樣就致使了系統的設計變得更加抽象，若是系統的業務規則比較複雜的話，使用組合模式就有必定的挑戰了。
模式結構
組合模式包含以下角色：
Component: 抽象構件
Leaf: 葉子構件
Composite: 容器構件
Client: 客戶類
9.裝飾模式
咱們能夠經過繼承和組合的方式來給一個對象添加行爲，雖然使用繼承可以很好擁有父類的行爲，可是它存在幾個缺陷：1、對象之間的關係複雜的話，系統變得複雜不利於維護。2、容易產生「類爆炸」現象。3、是靜態的。在這裏咱們能夠經過使用裝飾者模式來解決這個問題。
裝飾者模式，動態地將責任附加到對象上。若要擴展功能，裝飾者提供了比繼承更加有彈性的替代方案。雖然裝飾者模式可以動態將責任附加到對象上，可是他會產生許多的細小對象，增長了系統的複雜度。
模式結構
裝飾模式包含以下角色：
Component: 抽象構件
ConcreteComponent: 具體構件
Decorator: 抽象裝飾類
ConcreteDecorator: 具體裝飾類
10.外觀模式
咱們都知道類與類之間的耦合越低，那麼可複用性就越好，若是兩個類沒必要彼此通訊，那麼就不要讓這兩個類發生直接的相互關係，若是須要調用裏面的方法，能夠經過第三者來轉發調用。外觀模式很是好的詮釋了這段話。外觀模式提供了一個統一的接口，用來訪問子系統中的一羣接口。它讓一個應用程序中子系統間的相互依賴關係減小到了最少，它給子系統提供了一個簡單、單一的屏障，客戶經過這個屏障來與子系統進行通訊。經過使用外觀模式，使得客戶對子系統的引用變得簡單了，實現了客戶與子系統之間的鬆耦合。可是它違背了「開閉原則」，由於增長新的子系統可能須要修改外觀類或客戶端的源代碼。
外觀模式包含以下角色：
Facade: 外觀角色
SubSystem:子系統角色
11.亨元模式
在一個系統中對象會使得內存佔用過多，特別是那些大量重複的對象，這就是對系統資源的極大浪費。享元模式對對象的重用提供了一種解決方案，它使用共享技術對相同或者類似對象實現重用。享元模式就是運行共享技術有效地支持大量細粒度對象的複用。系統使用少許對象,並且這些都比較類似，狀態變化小，能夠實現對象的屢次複用。這裏有一點要注意：享元模式要求可以共享的對象必須是細粒度對象。享元模式經過共享技術使得系統中的對象個數大大減小了，同時享元模式使用了內部狀態和外部狀態，同時外部狀態相對獨立，不會影響到內部狀態，因此享元模式可以使得享元對象在不一樣的環境下被共享。同時正是分爲了內部狀態和外部狀態，享元模式會使得系統變得更加複雜，同時也會致使讀取外部狀態所消耗的時間過長。
享元模式包含以下角色：
Flyweight: 抽象享元類
ConcreteFlyweight: 具體享元類
UnsharedConcreteFlyweight: 非共享具體享元類
FlyweightFactory: 享元工廠類
12.代理模式
代理模式就是給一個對象提供一個代理，並由代理對象控制對原對象的引用。它使得客戶不能直接與真正的目標對象通訊。代理對象是目標對象的表明，其餘須要與這個目標對象打交道的操做都是和這個代理對象在交涉。
代理對象能夠在客戶端和目標對象之間起到中介的做用，這樣起到了的做用和保護了目標對象的，同時也在必定程度上面減小了系統的耦合度。
代理模式包含以下角色：
Subject: 抽象主題角色
Proxy: 代理主題角色
RealSubject: 真實主題角色
13.訪問者模式
訪問者模式俗稱23大設計模式中最難的一個。除告終構複雜外，理解也比較難。在咱們軟件開發中咱們可能會對同一個對象有不一樣的處理，若是咱們都作分別的處理，將會產生災難性的錯誤。對於這種問題，訪問者模式提供了比較好的解決方案。訪問者模式即表示一個做用於某對象結構中的各元素的操做，它使咱們能夠在不改變各元素的類的前提下定義做用於這些元素的新操做。
訪問者模式的目的是封裝一些施加於某種數據結構元素之上的操做，一旦這些操做須要修改的話，接受這個操做的數據結構能夠保持不變。爲不一樣類型的元素提供多種訪問操做方式，且能夠在不修改原有系統的狀況下增長新的操做方式。同時咱們還須要明確一點那就是訪問者模式是適用於那些數據結構比較穩定的，由於他是將數據的操做與數據結構進行分離了，若是某個系統的數據結構相對穩定，可是操做算法易於變化的話，就比較適用適用訪問者模式，由於訪問者模式使得算法操做的增長變得比較簡單了。
訪問者模式包含以下角色：
Vistor: 抽象訪問者
ConcreteVisitor: 具體訪問者
Element: 抽象元素
ConcreteElement: 具體元素
ObjectStructure: 對象結構
14.模板模式
有些時候咱們作某幾件事情的步驟都差很少，僅有那麼一小點的不一樣，在軟件開發的世界裏一樣如此，若是咱們都將這些步驟都一一作的話，費時費力不討好。因此咱們能夠將這些步驟分解、封裝起來，而後利用繼承的方式來繼承便可，固然不一樣的能夠本身重寫實現嘛！這就是模板方法模式提供的解決方案。
所謂模板方法模式就是在一個方法中定義一個算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類能夠在不改變算法結構的狀況下，從新定義算法中的某些步驟。
模板方法模式就是基於繼承的代碼複用技術的。在模板方法模式中，咱們能夠將相同部分的代碼放在父類中，而將不一樣的代碼放入不一樣的子類中。也就是說咱們須要聲明一個抽象的父類，將部分邏輯以具體方法以及具體構造函數的形式實現，而後聲明一些抽象方法讓子類來實現剩餘的邏輯，不一樣的子類能夠以不一樣的方式來實現這些邏輯。因此模板方法的模板其實就是一個普通的方法，只不過這個方法是將算法實現的步驟封裝起來的。
模板方法模式包含以下角色：
AbstractClass: 抽象類
ConcreteClass: 具體子類
15.策略模式
咱們知道一件事可能會有不少種方式來實現它，可是其中總有一種最高效的方式，在軟件開發的世界裏面一樣如此，咱們也有不少中方法來實現一個功能，可是咱們須要一種簡單、高效的方式來實現它，使得系統可以很是靈活，這就是策略模式。
因此策略模式就是定義了算法族，分別封裝起來，讓他們以前能夠互相轉換，此模式然該算法的變化獨立於使用算法的客戶。
在策略模式中它將這些解決問題的方法定義成一個算法羣，每個方法都對應着一個具體的算法，這裏的一個算法我就稱之爲一個策略。雖然策略模式定義了算法，可是它並不提供算法的選擇，即什麼算法對於什麼問題最合適這是策略模式所不關心的，因此對於策略的選擇仍是要客戶端來作。客戶必需要清楚的知道每一個算法之間的區別和在何時什麼地方使用什麼策略是最合適的，這樣就增長客戶端的負擔。
同時策略模式也很是完美的符合了「開閉原則」，用戶能夠在不修改原有系統的基礎上選擇算法或行爲，也能夠靈活地增長新的算法或行爲。可是一個策略對應一個類將會是系統產生不少的策略類。
策略模式包含以下角色：
Context: 環境類
Strategy: 抽象策略類
ConcreteStrategy: 具體策略類
16.狀態模式
在不少狀況下咱們對象的行爲依賴於它的一個或者多個變化的屬性，這些可變的屬性咱們稱之爲狀態，也就是說行爲依賴狀態，即當該對象由於在外部的互動而致使他的狀態發生變化，從而它的行爲也會作出相應的變化。對於這種狀況，咱們是不能用行爲來控制狀態的變化，而應該站在狀態的角度來思考行爲，便是什麼狀態就要作出什麼樣的行爲。這個就是狀態模式。
因此狀態模式就是容許對象在內部狀態發生改變時改變它的行爲，對象看起來好像修改了它的類。
在狀態模式中咱們能夠減小大塊的if…else語句，它是容許態轉換邏輯與狀態對象合成一體，可是減小if…else語句的代價就是會換來大量的類，因此狀態模式勢必會增長系統中類或者對象的個數。
同時狀態模式是將全部與某個狀態有關的行爲放到一個類中，而且能夠方便地增長新的狀態，只須要改變對象狀態便可改變對象的行爲。可是這樣就會致使系統的結構和實現都會比較複雜，若是使用不當就會致使程序的結構和代碼混亂，不利於維護。
狀態模式包含以下角色：
Context: 環境類
State: 抽象狀態類
ConcreteState: 具體狀態類
17.觀察者模式
何謂觀察者模式？觀察者模式定義了對象之間的一對多依賴關係，這樣一來，當一個對象改變狀態時，它的全部依賴者都會收到通知而且自動更新。
在這裏，發生改變的對象稱之爲觀察目標，而被通知的對象稱之爲觀察者。一個觀察目標能夠對應多個觀察者，並且這些觀察者之間沒有相互聯繫，因此麼能夠根據須要增長和刪除觀察者，使得系統更易於擴展。因此觀察者提供了一種對象設計，讓主題和觀察者之間以鬆耦合的方式結合。
觀察者模式包含以下角色：
Subject: 目標
ConcreteSubject: 具體目標
Observer: 觀察者
ConcreteObserver: 具體觀察者
18.備忘錄模式
後悔藥人人都想要，可是事實倒是殘酷的，根本就沒有後悔藥可買，可是也不只如此，在軟件的世界裏就有後悔藥！備忘錄模式就是一種後悔藥，它給咱們的軟件提供後悔藥的機制，經過它可使系統恢復到某一特定的歷史狀態。
所謂備忘錄模式就是在不破壞封裝的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態，這樣能夠在之後將對象恢復到原先保存的狀態。它實現了對信息的封裝，使得客戶不須要關心狀態保存的細節。保存就要消耗資源，因此備忘錄模式的缺點就在於消耗資源。若是類的成員變量過多，勢必會佔用比較大的資源，並且每一次保存都會消耗必定的內存。
備忘錄模式包含以下角色：
Originator: 原發器
Memento: 備忘錄
Caretaker: 負責人
19.中介者模式
租房各位都有過的經歷吧！在這個過程當中中介結構扮演着很重要的角色，它在這裏起到一箇中間者的做用，給咱們和房主互相傳遞信息。在外面軟件的世界裏一樣須要這樣一箇中間者。在咱們的系統中有時候會存在着對象與對象之間存在着很強、複雜的關聯關係，若是讓他們之間有直接的聯繫的話，一定會致使整個系統變得很是複雜，並且可擴展性不好！在前面咱們就知道若是兩個類之間沒有沒必要彼此通訊，咱們就不該該讓他們有直接的關聯關係，若是實在是須要通訊的話，咱們能夠經過第三者來轉發他們的請求。一樣，這裏咱們利用中介者來解決這個問題。
所謂中介者模式就是用一箇中介對象來封裝一系列的對象交互，中介者使各對象不須要顯式地相互引用，從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互。在中介者模式中，中介對象用來封裝對象之間的關係，各個對象能夠不須要知道具體的信息經過中介者對象就能夠實現相互通訊。它減小了對象之間的互相關係，提供了系統可複用性，簡化了系統的結構。
在中介者模式中，各個對象不須要互相知道了解，他們只須要知道中介者對象便可，可是中介者對象就必需要知道全部的對象和他們之間的關聯關係，正是由於這樣就致使了中介者對象的結構過於複雜，承擔了過多的職責，同時它也是整個系統的核心所在，它有問題將會致使整個系統的問題。因此若是在系統的設計過程當中若是出現「多對多」的複雜關係羣時，千萬別急着使用中介者模式，而是要仔細思考是否是您設計的系統存在問題。
Mediator: 抽象中介者
ConcreteMediator: 具體中介者
Colleague: 抽象同事類
ConcreteColleague: 具體同事類
20.迭代器模式
對於迭代在編程過程當中咱們常常用到，可以遊走於聚合內的每個元素，同時還能夠提供多種不一樣的遍歷方式，這就是迭代器模式的設計動機。在咱們實際的開發過程當中，咱們可能會須要根據不一樣的需求以不一樣的方式來遍歷整個對象，可是咱們又不但願在聚合對象的抽象接口中充斥着各類不一樣的遍歷操做，因而咱們就但願有某個東西可以以多種不一樣的方式來遍歷一個聚合對象，這時迭代器模式出現了。
何爲迭代器模式？所謂迭代器模式就是提供一種方法順序訪問一個聚合對象中的各個元素，而不是暴露其內部的表示。迭代器模式是將迭代元素的責任交給迭代器，而不是聚合對象，咱們甚至在不須要知道該聚合對象的內部結構就能夠實現該聚合對象的迭代。
經過迭代器模式，使得聚合對象的結構更加簡單，它不須要關注它元素的遍歷，只須要專一它應該專一的事情，這樣就更加符合單一職責原則了。
迭代器模式包含以下角色：
Iterator: 抽象迭代器
ConcreteIterator: 具體迭代器
Aggregate: 抽象聚合類
ConcreteAggregate: 具體聚合類
21.解釋器模式
所謂解釋器模式就是定義語言的文法，而且創建一個解釋器來解釋該語言中的句子。解釋器模式描述瞭如何構成一個簡單的語言解釋器，主要應用在使用面嚮對象語言開發的編譯器中。它描述瞭如何爲簡單的語言定義一個文法，如何在該語言中表示一個句子，以及如何解釋這些句子。
解釋器模式包含以下角色：
AbstractExpression: 抽象表達式
TerminalExpression: 終結符表達式
NonterminalExpression: 非終結符表達式
Context: 環境類
Client: 客戶類
22.命令模式
有些時候咱們想某個對象發送一個請求，可是咱們並不知道該請求的具體接收者是誰，具體的處理過程是如何的，們只知道在程序運行中指定具體的請求接收者便可，對於這樣將請求封裝成對象的咱們稱之爲命令模式。因此命令模式將請求封裝成對象，以便使用不一樣的請求、隊列或者日誌來參數化其餘對象。同時命令模式支持可撤銷的操做。
命令模式能夠將請求的發送者和接收者之間實現徹底的解耦，發送者和接收者之間沒有直接的聯繫，發送者只須要知道如何發送請求命令便可，其他的能夠一律無論，甚至命令是否成功都無需關心。同時咱們能夠很是方便的增長新的命令，可是可能就是由於方便和對請求的封裝就會致使系統中會存在過多的具體命令類。
命令模式包含以下角色：
Command: 抽象命令類
ConcreteCommand: 具體命令類
Invoker: 調用者
Receiver: 接收者
Client:客戶類
23.責任鏈模式
職責鏈模式描述的請求如何沿着對象所組成的鏈來傳遞的。它將對象組成一條鏈，發送者將請求發給鏈的第一個接收者，而且沿着這條鏈傳遞，直到有一個對象來處理它或者直到最後也沒有對象處理而留在鏈末尾端。
避免請求發送者與接收者耦合在一塊兒，讓多個對象都有可能接收請求，將這些對象鏈接成一條鏈，而且沿着這條鏈傳遞請求，直到有對象處理它爲止，這就是職責鏈模式。在職責鏈模式中，使得每個對象都有可能來處理請求，從而實現了請求的發送者和接收者之間的解耦。同時職責鏈模式簡化了對象的結構，它使得每一個對象都只須要引用它的後繼者便可，而沒必要了解整條鏈，這樣既提升了系統的靈活性也使得增長新的請求處理類也比較方便。可是在職責鏈中咱們不能保證全部的請求都可以被處理，並且不利於觀察運行時特徵。
職責鏈模式包含以下角色：
Handler: 抽象處理者
ConcreteHandler: 具體處理者
Client: 客戶類
5、如何學習設計模式
說明，《如何學習設計模式》轉摘自：http://blog.csdn.net/yqj2065/article/details/39103857
① 學習技巧
學習設計模式時，有一些技巧可以幫助你快速理解設計模式。
a) 使用較簡單的面向對象的語言如Java、C#。GoF的[設計模式]實質上是面向對象的設計模式。[GoF·1.1]中提到「程序設計語言的選擇很是重要，它將影響人們理解問題的出發點」。從學習設計模式的角度看，Java和C#較C++更容易一些。好比Java接口等，可以更有效展示設計模式的意圖。
b) 使用工具BlueJ。BlueJ最大的好處，就是提供了簡單的類圖。正如我在簡明設計模式Java中所作的，較少去專門畫類圖，而是在BlueJ中截圖。在學生上機編寫演示程序時，經常先看他的類圖，以判斷他的程序是否正確，必要時再看源代碼。
c) 平常生活的隱喻。用一些實際生活中的例子來講明某某模式，可以讓你快速掌握某模式的目的和實現代碼的結構。同時，你要認識到，這種隱喻如同告訴你（2+3）2=22+2*2*3+32，你須要本身觸類旁通，得出（a+b）2=a2+2ab+b2。在實際工做中的模式的具體應用，則至關於應用代數公式。
d) 動手實踐和懷疑精神。看顯淺的參考書或上網查閱資料時，要本身敲(複製也能夠)代碼並運行，要多修改別人的源代碼提出本身的觀點：爲何書中不這樣設計、爲何要那樣設計；若是增添一些方法、方法參數、或成員變量會如何？必需要本身親自動手，最起碼要運行。另外，要勇於向博主提問、拍磚。你甚至能夠質疑GoF的某些章節的解說和意圖，更況且一些博主呢。
② 基礎知識
這些知識讓你知道，設計模式好在何處。
a) 面向對象範式。也就是人們傳說的思想。封裝、繼承和多態這些東西，在我看來比if、for等稍微高一點，也屬於語法問題。面向對象編程要掌握的三大原則是柏拉圖(Plato)原則、里氏(Liskov)替換原則和Parnas原則。這三個原則其實很是簡單。任何原則，你以爲很難一見傾心，很難快速認同，那它就不會是好原則。
b) 設計原則。許多人列舉了7大原則，如單一職責原則、開閉原則、里氏代換原則、依賴倒轉原則、接口隔離原則、合成複用原則、迪米特法則。LSP，我將它提高爲面向對象範式的3大基石之一；單一職責和接口隔離，主要做爲面向對象分析/OOA時職責劃分所遵循的原則，此時你能夠不太在乎。依賴倒轉原則，我把它做爲垃圾扔掉，由於開閉原則或者直接地說「依賴於抽象類型原則」已經包含了依賴倒轉原則的精華，而依賴倒轉原則的糟粕由IoC繼承。固然，回調，我很強調。因此，你要掌握的有抽象依賴原則(OCP)、單向依賴原則(含對回調的學習)和最低依賴原則(合成複用原則、迪米特法則)。
c) UML的初步瞭解。這是學習設計模式的工具。在早期，你甚至能夠僅瞭解BlueJ的相關圖示，也就10分鐘的事情。
③ 境界
《五燈會元》卷十七中，有一則唐朝禪師青原唯信禪師的語錄:「老僧三十年前未參禪時，見山是山，見水是水。及至後來親見知識，有個入處，見山不是山，見水不是水。而今得個休歇處，依前見山只是山，見水只是水。」
a) 仔細研究GoF的[設計模式]，逐個學習其意圖和結構，是一個抱着字典學習英語的方式。見山是山，見水是水，致使你可能在實際工做中生搬硬套、東施效顰。
b) 建議從簡單的場景出發，本身發現或設計出某種模式。你從中體會該模式是如何解決問題的，這樣，該模式成爲你本身的東西，你纔不會出現知易行難的問題。全部的設計模式不過是基本原則和理念在特定場合的應用。你可能不知道某個設計模式的名字，可是你知道它一切的優缺點和變體以及應用場合。見山不是山，見水不是水。
c) 你對基本原則和理念融會貫通，你能夠可惜：「我找到一種模式，原來在[設計模式](實際上是某個特殊的書、文章提到的模式)中早就有了這種模式」。這時，模式不模式又如何呢？反模式又怎樣。看見一個模式，你會說：「嗯，這是一種有用的模式」。見山只是山，見水只是水。
以上一點淺見。
注：【】中的內容是我加的。
1 轉錄【IT168知識庫】
發現不少初學設計模式的人都有一些特色就是學習了某個設計模式以後，貌似理解了，可是殊不知道怎麼去使用這些所謂的精華經驗，苦於不知如何下手。我最初學習設計模式的時候也有相似的經驗，我將個人經驗分享出來，但願能對初學者有幫助。
我對設計模式產生興趣是在大概一年之前，最初看書的時候好像是看懂了，大概知道他在說什麼。看了幾個模式以後就開始尋找時機來套用套用這些模式。結果是除了Singleton模式之外的其餘模式都沒有找到應用的場所。而後我就沒開始看下去了，我知道再看也沒用，可是我並無放棄對設計模式的關注。
不久我就在MSDN的Webcast上看到李建忠的 C#面向對象設計模式縱橫談講座，很不錯的系列講座，讓我對設計模式有了新的理解。我意識到學習設計模式，確切的講是學習面向對象的設計模式，應該從學習面向對象開始。【面向對象的原理如同瞭解下象棋的規則，而設計模式至關於殘局，不知道規則看什麼殘局】因爲以前一年都在作asp.net開發，雖然都是在寫類、學着duwamish搞分層架構、搞類型化DataSet、也弄過自定義實體類，但好像一年下來還沒怎麼用過接口，什麼多態也是極少用。事實上對面向對象的編程思想的認識仍是很模糊的。
從新認識OO：面向對象編程是一種思想，以面向對象的思惟來思考軟件設計結構，從而強化面向對象的編程範式。面向對象的特色是封裝，繼承，多態【這些也算？】。因此從那是開始，當我設計一個類的時候，不斷的提示本身如下三點：
第一：別把本身的數據公開，除非你要向別人提供數據，使用盡可能低的訪問權限。
第二：以一個外部的視角來看類，緊記不要要求別人要在知道你是怎麼實現一個方法以後才能使用個人類。
第三：分清類的職責，該這個類作的事情就要在這個類中實現，不應個人類作的事情就讓別的類去實現。
在這三點的指導下來寫類，寫程序開始像在作「設計」了^_^。
一段時間後對設計模式就慢慢有感受了，並可以找到一些設計模式的應用場景了。並常套用套用那些模式，逐漸的加深對模式的理解，並把它變成本身的東西，可以在其餘的地方靈活的用起來。
2. 轉錄 《易學設計模式·1.4 如何學習設計模式》郭志學 人民郵電出版社
如何學習設計模式
在瞭解了設計模式的歷史和分類後，應該如何學習設計模式呢？在學習設計模式以前，讀者必定要樹立一種意識，那就是：設計模式並不僅是一種方法和技術，它更是一種思想、一個方法論。它和具體的語言沒有關係，學習設計模式最主要的目的就是要創建面向對象的思想，儘量地面向接口編程、低耦合、高內聚，使你設計的程序儘量地複用。【似是而非。學習設計模式可以更好理解面向對象的思想，設計模式是一些設計的技巧和竅門，不要上升到思想、方法論好很差】
有些軟件開發人員，在程序設計時，總想着往某個設計模式上套，其實這樣是不對的，並無真正掌握設計模式的思想。其實不少時候讀者用了某種設計模式，只是本身不知道這個模式叫什麼名字而已。所以，在程序設計時，要根據本身的理解，使用合適的設計模式。
而有另一些軟件開發人員，在程序設計時，動不動就給類起個相似模式的名字，好比叫某某Facade、某某Factory等，其實類裏面的內容和設計模式根本沒有一點關係，只是用來標榜本身懂設計模式而已。
所以，學習設計模式，首先要了解有哪些方面的設計模式能夠供開發人員使用，而後再分別研究每一個設計模式的原理，使用時機和方法，也就是說要在什麼狀況下才使用某個設計模式，在瞭解某個設計模式的使用時機時，還要了解此時若是不使用這個設計模式，會形成什麼樣的後果。當對每一個模式的原理和使用方法都瞭解了之後，更重要的是，學習面向對象的思想方式，在掌握面向對象的思想方式後，再回過頭來看設計模式，就會有更深入的理解，最後，學習設計模式，必定要勤學多練。【就最後一句很贊同】
6、我的感悟
學習設計模式確實有幾種境界：
第一種是學習了一兩個設計模式，就一直想用到本身的代碼中去；
第二種是學徹底部設計模式，以爲不少模式都很類似，分不清楚它們之間有什麼區別；
第三種是靈活運用設計模式，就算不用具體哪一種模式也能夠設計也高質量的代碼，無劍勝有劍。
最後附上總結圖：
本文分享自微信公衆號 - 業餘草（yyucao）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。