設計模式總結

      從七月份開始一直到九月底纔看完設計模式，在這個過程當中我不敢說我已經掌握了那本書裏面的內容，或者說1/5，沒能力說也沒有資格說。可是結果不重要，重要的是這個過程個人收穫！主要包括以下幾個方面：

      一、認識了這麼多設計模式。剛剛接觸java沒多久就在學長那裏聽過設計模式的大名，可是因爲能力有限，一直不敢觸碰。而今有幸將其都認識了。

      二、開始有設計的理論了。在接觸設計模式以前沒有怎麼想過設計方面東東，看到問題就立馬動手解決，沒有想到怎麼樣來設計更好，如何來是這塊更加優化、漂亮。

      三、開始考慮系統的可擴展性了。

      四、在遇到問題後開始想有那個設計模式會適用這個場景。

      五、對面向對象有了更深一步的瞭解。

      鄙人天資不聰慧，既不是聰明人，更不是那種天才，全部頓悟有限！！！閒話過多，先看以下兩幅圖片

設計模式之間的關係：

      設計模式總概況：

1、設計原則

一、單一職責原則

      一個類，只有一個引發它變化的緣由。應該只有一個職責。每個職責都是變化的一個軸線，若是一個類有一個以上的職責，這些職責就耦合在了一塊兒。這會致使脆弱的設計。當一個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一塊兒，會影響複用性。例如：要實現邏輯和界面的分離。from：百度百科

二、開閉原則（Open Close Principle）

      開閉原則就是說對擴展開放，對修改關閉。在程序須要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。因此一句話歸納就是：爲了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，咱們須要使用接口和抽象類，後面的具體設計中咱們會提到這點。

三、里氏代換原則（Liskov Substitution Principle）

      里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類能夠出現的地方，子類必定能夠出現。 LSP是繼承複用的基石，只有當衍生類能夠替換掉基類，軟件單位的功能不受到影響時，基類才能真正被複用，而衍生類也可以在基類的基礎上增長新的行爲。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。from：百度百科

四、依賴倒轉原則（Dependence Inversion Principle）

      所謂依賴倒置原則（Dependence Inversion Principle）就是要依賴於抽象，不要依賴於具體。簡單的說就是要求對抽象進行編程，不要對實現進行編程，這樣就下降了客戶與實現模塊間的耦合。

      實現開閉原則的關鍵是抽象化，而且從抽象化導出具體化實現，若是說開閉原則是面向對象設計的目標的話，那麼依賴倒轉原則就是面向對象設計的主要手段。 from：百度百科

五、接口隔離原則（Interface Segregation Principle）

      這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。仍是一個下降類之間的耦合度的意思，從這兒咱們看出，其實設計模式就是一個軟件的設計思想，從大型軟件架構出發，爲了升級和維護方便。因此上文中屢次出現：下降依賴，下降耦合。

六、合成複用原則（Composite Reuse Principle）

      合成複用原則就是指在一個新的對象裏經過關聯關係（包括組合關係和聚合關係）來使用一些已有的對象，使之成爲新對象的一部分；新對象經過委派調用已有對象的方法達到複用其已有功能的目的。簡言之：要儘可能使用組合/聚合關係，少用繼承。

七、迪米特法則（最少知道原則）（Demeter Principle）

      爲何叫最少知道原則，就是說：一個實體應當儘可能少的與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。也就是說一個軟件實體應當儘量少的與其餘實體發生相互做用。這樣，當一個模塊修改時，就會盡可能少的影響其餘的模塊，擴展會相對容易，這是對軟件實體之間通訊的限制，它要求限制軟件實體之間通訊的寬度和深度。

2、建立型模式

      在軟件工程中，建立型模式是處理對象建立的設計模式，試圖根據實際狀況使用合適的方式建立對象。基本的對象建立方式可能會致使設計上的問題，或增長設計的複雜度。建立型模式經過以某種方式控制對象的建立來解決問題。

      建立型模式由兩個主導思想構成。一是將系統使用的具體類封裝起來，二是隱藏這些具體類的實例建立和結合的方式。

      建立型模式又分爲對象建立型模式和類建立型模式。對象建立型模式處理對象的建立，類建立型模式處理類的建立。詳細地說，對象建立型模式把對象建立的一部分推遲到另外一個對象中，而類建立型模式將它對象的建立推遲到子類中。

一、抽象工廠模式(Abstract Factory)

      所謂抽象工廠模式就是她提供一個接口，用於建立相關或者依賴對象的家族，而不須要明確指定具體類。他容許客戶端使用抽象的接口來建立一組相關的產品，而不須要關係實際產出的具體產品是什麼。這樣一來，客戶就能夠從具體的產品中被解耦。它的優勢是隔離了具體類的生成，使得客戶端不須要知道什麼被建立了，而缺點就在於新增新的行爲會比較麻煩，由於當添加一個新的產品對象時，須要更加須要更改接口及其下全部子類。其UML結構圖以下：

      參與者：

         AbstractFactory：抽象工廠。抽象工廠定義了一個接口，全部的具體工廠都必須實現此接口，這個接口包含了一組方法用來生產產品。

         ConcreteFactory：具體工廠。具體工廠是用於生產不一樣產品族。要建立一個產品，客戶只須要使用其中一個工廠徹底不須要實例化任何產品對象。

         AbstractProduct：抽象產品。這是一個產品家族，每個具體工廠都可以生產一整組產品。

         Product：具體產品。

二、建造者模式(Builder)

      對於建造者模式而已，它主要是將一個複雜對象的構建與表示分離，使得一樣的構建過程能夠建立不一樣的表示。適用於那些產品對象的內部結構比較複雜。

      建造者模式將複雜產品的構建過程封裝分解在不一樣的方法中，使得建立過程很是清晰，可以讓咱們更加精確的控制複雜產品對象的建立過程，同時它隔離了複雜產品對象的建立和使用，使得相同的建立過程可以建立不一樣的產品。可是若是某個產品的內部結構過於複雜，將會致使整個系統變得很是龐大，不利於控制，同時若幾個產品之間存在較大的差別，則不適用建造者模式，畢竟這個世界上存在相同點大的兩個產品並非不少，因此它的使用範圍有限。其UML結構圖：

       參與者：

         Builder：抽象建造者。它聲明爲建立一個Product對象的各個部件指定的抽象接口。
         ConcreteBuilder：具體建造者。實現抽象接口，構建和裝配各個部件。
         Director：指揮者。構建一個使用Builder接口的對象。它主要是用於建立一個複雜的對象，它主要有兩個做用，一是：隔離了客戶與對象的生產過程，二是：負責控制產品對象的生產過程。
         Product：產品角色。一個具體的產品對象。

三、工廠方法模式(Factory Method)

      做爲抽象工廠模式的孿生兄弟，工廠方法模式定義了一個建立對象的接口，但由子類決定要實例化的類是哪個，也就是說工廠方法模式讓實例化推遲到子類。

      工廠方法模式很是符合「開閉原則」，當須要增長一個新的產品時，咱們只須要增長一個具體的產品類和與之對應的具體工廠便可，無須修改原有系統。同時在工廠方法模式中用戶只須要知道生產產品的具體工廠便可，無須關係產品的建立過程，甚至連具體的產品類名稱都不須要知道。雖然他很好的符合了「開閉原則」，可是因爲每新增一個新產品時就須要增長兩個類，這樣勢必會致使系統的複雜度增長。其UML結構圖：

 

      參與者：

          Product：抽象產品。全部的產品必須實現這個共同的接口，這樣一來，使用這些產品的類既能夠引用這個接口。而不是具體類 。

         ConcreteProduct：具體產品。

         Creator：抽象工廠。它實現了全部操縱產品的方法，但不實現工廠方法。Creator全部的子類都必需要實現factoryMethod()方法。

         ConcreteCreator：具體工廠。製造產品的實際工廠。它負責建立一個或者多個具體產品，只有ConcreteCreator類知道如何建立這些產品。

四、原型模式(Prototype)

      在咱們應用程序可能有某些對象的結構比較複雜，可是咱們又須要頻繁的使用它們，若是這個時候咱們來不斷的新建這個對象勢必會大大損耗系統內存的，這個時候咱們須要使用原型模式來對這個結構複雜又要頻繁使用的對象進行克隆。因此原型模式就是用原型實例指定建立對象的種類，而且經過複製這些原型建立新的對象。

      它主要應用與那些建立新對象的成本過大時。它的主要優勢就是簡化了新對象的建立過程，提升了效率，同時原型模式提供了簡化的建立結構。UML結構圖：

 

       參與者：

          Prototype：抽象原型類。聲明克隆自身的接口。
          ConcretePrototype：具體原型類。實現克隆的具體操做。
          Client：客戶類。讓一個原型克隆自身，從而得到一個新的對象。

五、單例模式(Singleton)

      單例模式，從字面上看就是一個實例的意思。因此它的定義就是確保某一個類只有一個實例，而且提供一個全局訪問點。

      單例模式具有以下幾個特色：

          一、只有一個實例。

          二、可以自我實例化。

          三、提供全局訪問點。

      因此說當系統中只須要一個實例對象或者系統中只容許一個公共訪問點，除了這個公共訪問點外，不能經過其餘訪問點訪問該實例時，可使用單例模式。

       單例模式的主要優勢就是節約系統資源、提升了系統效率，同時也可以嚴格控制客戶對它的訪問。也許就是由於系統中只有一個實例，這樣就致使了單例類的職責太重，違背了「單一職責原則」，同時也沒有抽象類，因此擴展起來有必定的困難。其UML結構圖很是簡單，就只有一個類：

 

      參與者：

         Singleton：單例。

3、結構型模式

      結構型模式主要是用於處理類或者對象的組合，它描述瞭如何來類或者對象更好的組合起來，是從程序的結構上來解決模塊之間的耦合問題。它主要包括適配器模式、橋接模式、組合模式、裝飾模式、外觀模式、享元模式、代理模式這個七個模式。

一、適配器模式(Adapter)

      在咱們的應用程序中咱們可能須要將兩個不一樣接口的類來進行通訊，在不修改這兩個的前提下咱們可能會須要某個中間件來完成這個銜接的過程。這個中間件就是適配器。所謂適配器模式就是將一個類的接口，轉換成客戶指望的另外一個接口。它可讓本來兩個不兼容的接口可以無縫完成對接。

      做爲中間件的適配器將目標類和適配者解耦，增長了類的透明性和可複用性。

      參與者：

         Target：目標抽象類 。

         Adapter：適配器類 。經過在內部包裝一個Adaptee，將源接口轉成目標接口。

         Adaptee：適配者類 。須要適配的類。

         Client：客戶類。

二、橋接模式(Bridge)

      若是說某個系統可以從多個角度來進行分類，且每一種分類均可能會變化，那麼咱們須要作的就是講這多個角度分離出來，使得他們能獨立變化，減小他們之間的耦合，這個分離過程就使用了橋接模式。所謂橋接模式就是講抽象部分和實現部分隔離開來，使得他們可以獨立變化。

      橋接模式將繼承關係轉化成關聯關係，封裝了變化，完成了解耦，減小了系統中類的數量，也減小了代碼量。

      參與者

         Abstraction：抽象類。
         RefinedAbstraction：擴充抽象類。
         Implementor：實現類接口。
         ConcreteImplementor：具體實現類 。

 

三、組合模式(Composite)

      組合模式組合多個對象造成樹形結構以表示「總體-部分」的結構層次。它定義瞭如何將容器對象和葉子對象進行遞歸組合，使得客戶在使用的過程當中無須進行區分，能夠對他們進行一致的處理。

      在使用組合模式中須要注意一點也是組合模式最關鍵的地方：葉子對象和組合對象實現相同的接口。這就是組合模式可以將葉子節點和對象節點進行一致處理的緣由。

      雖然組合模式可以清晰地定義分層次的複雜對象，也使得增長新構件也更容易，可是這樣就致使了系統的設計變得更加抽象，若是系統的業務規則比較複雜的話，使用組合模式就有必定的挑戰了。

      參與者：

         Component ：組合中的對象聲明接口，在適當的狀況下，實現全部類共有接口的默認行爲。聲明一個接口用於訪問和管理Component子部件。
         Leaf：葉子對象。葉子結點沒有子結點。
         Composite：容器對象，定義有枝節點行爲，用來存儲子部件，在Component接口中實現與子部件有關操做，如增長(add)和刪除(remove)等。

四、裝飾者模式(Decorator)

      咱們能夠經過繼承和組合的方式來給一個對象添加行爲，雖然使用繼承可以很好擁有父類的行爲，可是它存在幾個缺陷：1、對象之間的關係複雜的話，系統變得複雜不利於維護。2、容易產生「類爆炸」現象。3、是靜態的。在這裏咱們能夠經過使用裝飾者模式來解決這個問題。

      裝飾者模式，動態地將責任附加到對象上。若要擴展功能，裝飾者提供了比繼承更加有彈性的替代方案。雖然裝飾者模式可以動態將責任附加到對象上，可是他會產生許多的細小對象，增長了系統的複雜度。

      參與者：

         Component: 抽象構件。是定義一個對象接口，能夠給這些對象動態地添加職責。

         ConcreteComponent:具體構件。是定義了一個具體的對象，也能夠給這個對象添加一些職責。

         Decorator: 抽象裝飾類。是裝飾抽象類，繼承了Component,從外類來擴展Component類的功能，但對於Component來講，是無需知道Decorator存在的。

         ConcreteDecorator:具體裝飾類，起到給Component添加職責的功能。

五、外觀模式(Facade)

      咱們都知道類與類之間的耦合越低，那麼可複用性就越好，若是兩個類沒必要彼此通訊，那麼就不要讓這兩個類發生直接的相互關係，若是須要調用裏面的方法，能夠經過第三者來轉發調用。外觀模式很是好的詮釋了這段話。外觀模式提供了一個統一的接口，用來訪問子系統中的一羣接口。它讓一個應用程序中子系統間的相互依賴關係減小到了最少，它給子系統提供了一個簡單、單一的屏障，客戶經過這個屏障來與子系統進行通訊。

      經過使用外觀模式，使得客戶對子系統的引用變得簡單了，實現了客戶與子系統之間的鬆耦合。可是它違背了「開閉原則」，由於增長新的子系統可能須要修改外觀類或客戶端的源代碼。

      參與者：

         Facade: 外觀角色。知道哪些子系統類負責處理請求，將客戶的請求代理給適合的子系統處理。

         SubSystem:子系統角色。實現子系統功能，處理Facade對象發來的請求。

六、享元模式(Flyweight)

      在一個系統中對象會使得內存佔用過多，特別是那些大量重複的對象，這就是對系統資源的極大浪費。享元模式對對象的重用提供了一種解決方案，它使用共享技術對相同或者類似對象實現重用。

      享元模式就是運行共享技術有效地支持大量細粒度對象的複用。系統使用少許對象,並且這些都比較類似，狀態變化小，能夠實現對象的屢次複用。這裏有一點要注意：享元模式要求可以共享的對象必須是細粒度對象。

      享元模式經過共享技術使得系統中的對象個數大大減小了，同時享元模式使用了內部狀態和外部狀態，同時外部狀態相對獨立，不會影響到內部狀態，因此享元模式可以使得享元對象在不一樣的環境下被共享。同時正是分爲了內部狀態和外部狀態，享元模式會使得系統變得更加複雜，同時也會致使讀取外部狀態所消耗的時間過長。

      參與者：

         Flyweight: 抽象享元類。全部具體享元類的超類或者接口，經過這個接口，Flyweight能夠接受並做用於外部專題。
         ConcreteFlyweight: 具體享元類。指定內部狀態，爲內部狀態增長存儲空間。
         UnsharedConcreteFlyweight: 非共享具體享元類。指出那些不須要共享的Flyweight子類。
         FlyweightFactory: 享元工廠類。用來建立並管理Flyweight對象，它主要用來確保合理地共享Flyweight，當用戶請求一個Flyweight時，FlyweightFactory就會提供一個已經建立的Flyweight對象或者新建一個（若是不存在）。

七、代理模式(Proxy)、

      代理模式就是給一個對象提供一個代理，並由代理對象控制對原對象的引用。它使得客戶不能直接與真正的目標對象通訊。代理對象是目標對象的表明，其餘須要與這個目標對象打交道的操做都是和這個代理對象在交涉。

      代理對象能夠在客戶端和目標對象之間起到中介的做用，這樣起到了的做用和保護了目標對象的，同時也在必定程度上面減小了系統的耦合度。

      參與者：

         Subject: 抽象角色。聲明真實對象和代理對象的共同接口。

         Proxy: 代理角色。代理對象與真實對象實現相同的接口，因此它可以在任什麼時候刻都可以代理真實對象。代理角色內部包含有對真實對象的引用，因此她能夠操做真實對象，同時也能夠附加其餘的操做，至關於對真實對象進行封裝。

         RealSubject: 真實角色。它表明着真實對象，是咱們最終要引用的對象。

4、行爲型模式

      行爲型模式主要是用於描述類或者對象是怎樣交互和怎樣分配職責的。它涉及到算法和對象間的職責分配，不只描述對象或者類的模式，還描述了他們之間的通訊方式，它將你的注意力從控制流轉移到了對象間的關係上來。行爲型類模式採用繼承機制在類間分派行爲，而行爲型對象模式使用對象複合而不是繼承。它主要包括如何11中設計模式：職責鏈模式、命令模式、解釋器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態模式、策略模式、模板方法模式、訪問者模式。

一、職責鏈模式(Chain of Responsibility)

       職責鏈模式描述的請求如何沿着對象所組成的鏈來傳遞的。它將對象組成一條鏈，發送者將請求發給鏈的第一個接收者，而且沿着這條鏈傳遞，直到有一個對象來處理它或者直到最後也沒有對象處理而留在鏈末尾端。

      避免請求發送者與接收者耦合在一塊兒，讓多個對象都有可能接收請求，將這些對象鏈接成一條鏈，而且沿着這條鏈傳遞請求，直到有對象處理它爲止，這就是職責鏈模式。在職責鏈模式中，使得每個對象都有可能來處理請求，從而實現了請求的發送者和接收者之間的解耦。同時職責鏈模式簡化了對象的結構，它使得每一個對象都只須要引用它的後繼者便可，而沒必要了解整條鏈，這樣既提升了系統的靈活性也使得增長新的請求處理類也比較方便。可是在職責鏈中咱們不能保證全部的請求都可以被處理，並且不利於觀察運行時特徵。

      參與者：

         Handler: 抽象處理者。定義了一個處理請求的方法。全部的處理者都必須實現該抽象類。
         ConcreteHandler: 具體處理者。處理它所負責的請求，同時也能夠訪問它的後繼者。若是它可以處理該請求則處理，不然將請求傳遞到它的後繼者。
         Client: 客戶類。

二、命令模式(Command)

      有些時候咱們想某個對象發送一個請求，可是咱們並不知道該請求的具體接收者是誰，具體的處理過程是如何的，們只知道在程序運行中指定具體的請求接收者便可，對於這樣將請求封裝成對象的咱們稱之爲命令模式。因此命令模式將請求封裝成對象，以便使用不一樣的請求、隊列或者日誌來參數化其餘對象。同時命令模式支持可撤銷的操做。

      命令模式能夠將請求的發送者和接收者之間實現徹底的解耦，發送者和接收者之間沒有直接的聯繫，發送者只須要知道如何發送請求命令便可，其他的能夠一律無論，甚至命令是否成功都無需關心。同時咱們能夠很是方便的增長新的命令，可是可能就是由於方便和對請求的封裝就會致使系統中會存在過多的具體命令類。

       參與者：

          Command: 抽象命令類。用來聲明執行操做的接口。

          ConcreteCommand: 具體命令類。將一個接收者對象綁定於一個動做，調用接收者相應的操做，以實現Excute。

         Invoker: 調用者。要求該命令執行這個請求。

         Receiver: 接收者。知道如何實施與執行一個請求相關的操做，任何類都有可能成爲一個接收者。

         Client:客戶類。

三、解釋器模式(Interpreter)

       所謂解釋器模式就是定義語言的文法，而且創建一個解釋器來解釋該語言中的句子。解釋器模式描述瞭如何構成一個簡單的語言解釋器，主要應用在使用面嚮對象語言開發的編譯器中。它描述瞭如何爲簡單的語言定義一個文法，如何在該語言中表示一個句子，以及如何解釋這些句子。

      參與者：

         AbstractExpression: 抽象表達式。聲明一個抽象的解釋操做，該接口爲抽象語法樹中全部的節點共享。

         TerminalExpression: 終結符表達式。實現與文法中的終結符相關的解釋操做。實現抽象表達式中所要求的方法。文法中每個終結符都有一個具體的終結表達式與之相對應。

         NonterminalExpression: 非終結符表達式。爲文法中的非終結符相關的解釋操做。

         Context: 環境類。包含解釋器以外的一些全局信息。

         Client: 客戶類。

四、迭代器模式(Iterator)

     對於迭代在編程過程當中咱們常常用到，可以遊走於聚合內的每個元素，同時還能夠提供多種不一樣的遍歷方式，這就是迭代器模式的設計動機。在咱們實際的開發過程當中，咱們可能會須要根據不一樣的需求以不一樣的方式來遍歷整個對象，可是咱們又不但願在聚合對象的抽象接口中充斥着各類不一樣的遍歷操做，因而咱們就但願有某個東西可以以多種不一樣的方式來遍歷一個聚合對象，這時迭代器模式出現了。

      何爲迭代器模式？所謂迭代器模式就是提供一種方法順序訪問一個聚合對象中的各個元素，而不是暴露其內部的表示。迭代器模式是將迭代元素的責任交給迭代器，而不是聚合對象，咱們甚至在不須要知道該聚合對象的內部結構就能夠實現該聚合對象的迭代。

      經過迭代器模式，使得聚合對象的結構更加簡單，它不須要關注它元素的遍歷，只須要專一它應該專一的事情，這樣就更加符合單一職責原則了。

       參與者：

          Iterator: 抽象迭代器：全部迭代器都須要實現的接口，提供了遊走聚合對象元素之間的方法。

          ConcreteIterator: 具體迭代器。利用這個具體的迭代器可以對具體的聚合對象進行遍歷。每個聚合對象都應該對應一個具體的迭代器。

          Aggregate: 抽象聚合類。

          ConcreteAggregate: 具體聚合類。實現creatorIterator()方法，返回該聚合對象的迭代器。

五、中介者模式(Mediator)

      租房各位都有過的經歷吧！在這個過程當中中介結構扮演着很重要的角色，它在這裏起到一箇中間者的做用，給咱們和房主互相傳遞信息。在外面軟件的世界裏一樣須要這樣一箇中間者。在咱們的系統中有時候會存在着對象與對象之間存在着很強、複雜的關聯關係，若是讓他們之間有直接的聯繫的話，一定會致使整個系統變得很是複雜，並且可擴展性不好！在前面咱們就知道若是兩個類之間沒有沒必要彼此通訊，咱們就不該該讓他們有直接的關聯關係，若是實在是須要通訊的話，咱們能夠經過第三者來轉發他們的請求。一樣，這裏咱們利用中介者來解決這個問題。

      所謂中介者模式就是用一箇中介對象來封裝一系列的對象交互，中介者使各對象不須要顯式地相互引用，從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互。在中介者模式中，中介對象用來封裝對象之間的關係，各個對象能夠不須要知道具體的信息經過中介者對象就能夠實現相互通訊。它減小了對象之間的互相關係，提供了系統可複用性，簡化了系統的結構。

      在中介者模式中，各個對象不須要互相知道了解，他們只須要知道中介者對象便可，可是中介者對象就必需要知道全部的對象和他們之間的關聯關係，正是由於這樣就致使了中介者對象的結構過於複雜，承擔了過多的職責，同時它也是整個系統的核心所在，它有問題將會致使整個系統的問題。因此若是在系統的設計過程當中若是出現「多對多」的複雜關係羣時，千萬別急着使用中介者模式，而是要仔細思考是否是您設計的系統存在問題。

      參與者：

         Mediator: 抽象中介者。定義了同事對象到中介者對象之間的接口。

         ConcreteMediator: 具體中介者。實現抽象中介者的方法，它須要知道全部的具體同事類，同時須要從具體的同事類那裏接收信息，而且向具體的同事類發送信息。

         Colleague: 抽象同事類。

         ConcreteColleague: 具體同事類。每一個具體同事類都只須要知道本身的行爲便可，可是他們都須要認識中介者。

六、備忘錄模式(Memento)

     後悔藥人人都想要，可是事實倒是殘酷的，根本就沒有後悔藥可買，可是也不只如此，在軟件的世界裏就有後悔藥！備忘錄模式就是一種後悔藥，它給咱們的軟件提供後悔藥的機制，經過它可使系統恢復到某一特定的歷史狀態。

      所謂備忘錄模式就是在不破壞封裝的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態，這樣能夠在之後將對象恢復到原先保存的狀態。它實現了對信息的封裝，使得客戶不須要關心狀態保存的細節。保存就要消耗資源，因此備忘錄模式的缺點就在於消耗資源。若是類的成員變量過多，勢必會佔用比較大的資源，並且每一次保存都會消耗必定的內存。

      參與者：

         Originator: 原發器。負責建立一個備忘錄，用以記錄當前對象的內部狀態，經過也可使用它來利用備忘錄恢復內部狀態。同時原發器還能夠根據須要決定Memento存儲Originator的那些內部狀態。

         Memento: 備忘錄。用於存儲Originator的內部狀態，而且能夠防止Originator之外的對象訪問Memento。在備忘錄Memento中有兩個接口，其中Caretaker只能看到備忘錄中的窄接口，它只能將備忘錄傳遞給其餘對象。Originator能夠看到寬接口，容許它訪問返回到先前狀態的全部數據。

         Caretaker: 負責人。負責保存好備忘錄，不能對備忘錄的內容進行操做和訪問，只可以將備忘錄傳遞給其餘對象。

七、觀察者模式(Observer)

      何謂觀察者模式？觀察者模式定義了對象之間的一對多依賴關係，這樣一來，當一個對象改變狀態時，它的全部依賴者都會收到通知而且自動更新。

      在這裏，發生改變的對象稱之爲觀察目標，而被通知的對象稱之爲觀察者。一個觀察目標能夠對應多個觀察者，並且這些觀察者之間沒有相互聯繫，因此麼能夠根據須要增長和刪除觀察者，使得系統更易於擴展。

      因此觀察者提供了一種對象設計，讓主題和觀察者之間以鬆耦合的方式結合。

      參與者：

          Subject：目標。他把全部對觀察者對戲的引用保存在一個彙集裏，每個主題均可以有多個觀察者。

          Observer：觀察者。爲全部的具體觀察者定義一個接口，在獲得主題的通知時可以及時的更新本身。

          ConcreteSubject：具體主題。將有關狀態存入具體觀察者對象。在具體主題發生改變時，給全部的觀察者發出通知。

          ConcreteObserver：具體觀察者。實現抽象觀察者角色所要求的更新接口，以便使自己的狀態與主題狀態相協調。

八、狀態模式(State)

      在不少狀況下咱們對象的行爲依賴於它的一個或者多個變化的屬性，這些可變的屬性咱們稱之爲狀態，也就是說行爲依賴狀態，即當該對象由於在外部的互動而致使他的狀態發生變化，從而它的行爲也會作出相應的變化。對於這種狀況，咱們是不能用行爲來控制狀態的變化，而應該站在狀態的角度來思考行爲，便是什麼狀態就要作出什麼樣的行爲。這個就是狀態模式。

      因此狀態模式就是容許對象在內部狀態發生改變時改變它的行爲，對象看起來好像修改了它的類。

      在狀態模式中咱們能夠減小大塊的if…else語句，它是容許態轉換邏輯與狀態對象合成一體，可是減小if…else語句的代價就是會換來大量的類，因此狀態模式勢必會增長系統中類或者對象的個數。

      同時狀態模式是將全部與某個狀態有關的行爲放到一個類中，而且能夠方便地增長新的狀態，只須要改變對象狀態便可改變對象的行爲。可是這樣就會致使系統的結構和實現都會比較複雜，若是使用不當就會致使程序的結構和代碼混亂，不利於維護。

      參與者：

         Context：環境類。能夠包括一些內部狀態。
         State： 抽象狀態類。State定義了一個全部具體狀態的共同接口，任何狀態都實現這個相同的接口，這樣一來，狀態之間就能夠互相轉換了。
         ConcreteState：具體狀態類。具體狀態類，用於處理來自Context的請求，每個ConcreteState都提供了它對本身請求的實現，因此，當Context改變狀態時行爲也會跟着改變。

九、策略模式(Strategy)

      咱們知道一件事可能會有不少種方式來實現它，可是其中總有一種最高效的方式，在軟件開發的世界裏面一樣如此，咱們也有不少中方法來實現一個功能，可是咱們須要一種簡單、高效的方式來實現它，使得系統可以很是靈活，這就是策略模式。

      因此策略模式就是定義了算法族，分別封裝起來，讓他們以前能夠互相轉換，此模式然該算法的變化獨立於使用算法的客戶。

      在策略模式中它將這些解決問題的方法定義成一個算法羣，每個方法都對應着一個具體的算法，這裏的一個算法我就稱之爲一個策略。雖然策略模式定義了算法，可是它並不提供算法的選擇，即什麼算法對於什麼問題最合適這是策略模式所不關心的，因此對於策略的選擇仍是要客戶端來作。客戶必需要清楚的知道每一個算法之間的區別和在何時什麼地方使用什麼策略是最合適的，這樣就增長客戶端的負擔。

      同時策略模式也很是完美的符合了「開閉原則」，用戶能夠在不修改原有系統的基礎上選擇算法或行爲，也能夠靈活地增長新的算法或行爲。可是一個策略對應一個類將會是系統產生不少的策略類。

      參與者：

         Context: 環境類。維護一個Strategy對象的引用，用一個ConcreteStrategy來配置，可定義一個接口來讓Strategy訪問它的數據。
         Strategy: 抽象策略類。定義全部支持算法的公共接口。Context使用這個接口來調用某個Concretestrategy定義的算法。
         ConcreteStrategy: 具體策略類。封裝了具體的算法實現。

十、模板方法模式(Template Method)

      有些時候咱們作某幾件事情的步驟都差很少，僅有那麼一小點的不一樣，在軟件開發的世界裏一樣如此，若是咱們都將這些步驟都一一作的話，費時費力不討好。因此咱們能夠將這些步驟分解、封裝起來，而後利用繼承的方式來繼承便可，固然不一樣的能夠本身重寫實現嘛！這就是模板方法模式提供的解決方案。

      所謂模板方法模式就是在一個方法中定義一個算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類能夠在不改變算法結構的狀況下，從新定義算法中的某些步驟。

      模板方法模式就是基於繼承的代碼複用技術的。在模板方法模式中，咱們能夠將相同部分的代碼放在父類中，而將不一樣的代碼放入不一樣的子類中。也就是說咱們須要聲明一個抽象的父類，將部分邏輯以具體方法以及具體構造函數的形式實現，而後聲明一些抽象方法讓子類來實現剩餘的邏輯，不一樣的子類能夠以不一樣的方式來實現這些邏輯。因此模板方法的模板其實就是一個普通的方法，只不過這個方法是將算法實現的步驟封裝起來的。

 

      參與者：

         AbstractClass: 抽象類。實現了一個模板，實現算法的基本骨架，具體子類將重定義primitiveOperation()方法以實現一個算法步驟。

         ConcreteClass:  具體子類。實現primitiveOperation()方法以完成算法中與特定子類相關的步驟。

十一、訪問者模式(Visitor)

      訪問者模式俗稱23大設計模式中最難的一個。除告終構複雜外，理解也比較難。在咱們軟件開發中咱們可能會對同一個對象有不一樣的處理，若是咱們都作分別的處理，將會產生災難性的錯誤。對於這種問題，訪問者模式提供了比較好的解決方案。

     訪問者模式即表示一個做用於某對象結構中的各元素的操做，它使咱們能夠在不改變各元素的類的前提下定義做用於這些元素的新操做。

      訪問者模式的目的是封裝一些施加於某種數據結構元素之上的操做，一旦這些操做須要修改的話，接受這個操做的數據結構能夠保持不變。爲不一樣類型的元素提供多種訪問操做方式，且能夠在不修改原有系統的狀況下增長新的操做方式。同時咱們還須要明確一點那就是訪問者模式是適用於那些數據結構比較穩定的，由於他是將數據的操做與數據結構進行分離了，若是某個系統的數據結構相對穩定，可是操做算法易於變化的話，就比較適用適用訪問者模式，由於訪問者模式使得算法操做的增長變得比較簡單了。

      參與者：

         Vistor: 抽象訪問者。爲該對象結構中的ConcreteElement的每個類聲明的一個操做。
         ConcreteVisitor: 具體訪問者。實現Visitor申明的每個操做，每個操做實現算法的一部分。
         Element: 抽象元素。定義一個Accept操做，它以一個訪問者爲參數。
         ConcreteElement: 具體元素 。實現Accept操做。
         ObjectStructure: 對象結構。可以枚舉它的元素，能夠提供一個高層的接口來容許訪問者訪問它的元素。

5、更多

      上面只是對各個設計模式的一個簡單的總結，下面我將列出詳情，各位看客有興趣的能夠點點：

         0一、設計模式讀書筆記-----簡單工廠模式

         0二、設計模式讀書筆記-----工廠方法模式

         0三、設計模式讀書筆記-----抽象工廠模式

         0四、設計模式讀書筆記-----建造者模式

         0五、設計模式讀書筆記-----原型模式

         0六、設計模式讀書筆記-----單例模式

         0七、設計模式讀書筆記-----適配器模式

         0八、設計模式讀書筆記-----橋接模式

         0九、設計模式讀書筆記-----組合模式

         十、設計模式讀書筆記-----裝飾者模式

         十一、設計模式讀書筆記-----外觀模式

         十二、設計模式讀書筆記----享元模式

         1三、設計模式讀書筆記-----代理模式

         1四、設計模式讀書筆記-----職責鏈模式

         1五、設計模式讀書筆記-----命令模式

         1六、設計模式讀書筆記-----解釋器模式

         1七、設計模式讀書筆記-----迭代器模式

         1八、設計模式讀書筆記-----中介者模式

         1九、設計模式讀書筆記-----備忘錄模式

         20、設計模式讀書筆記-----觀察者模式

         2一、設計模式讀書筆記-----狀態模式

         2二、設計模式讀書筆記-----策略模式

         2三、設計模式讀書筆記-----模板方法模式

         2四、設計模式讀書筆記-----訪問者模式

6、最後

      感謝Eric Freeman , Elisabeth Freeman , Kathy Sierra & Bert Bates所編寫的《Head First design patterns》，正是這本書將我領入設計模式的大門，雖然只是剛剛跨過門檻，但早已陶醉於那濃濃的、醇正的知識香中。還要感謝劉偉老師的PPT，您的教程給了我一個很好的參考。

      雖然看完了設計模式，但這並非結束，而是剛剛開始，在之後的項目過程當中，我會盡可能去優化，思考。

      誠然，最近在作項目的過程當中深感基礎不夠紮實，因此下一步就是java基礎了：think in java ,I must conquer you!!!!

      博文有點兒長，感謝各位看客可以看完，若是以爲不錯，請推薦個吧！！！！