23種設計模式全解析

1. public interface Sender {  
2.     public void Send();  
3. }  

1. public class MailSender implements Sender {  
2.     @Override  
3.     public void Send() {  
4.         System.out.println("this is mailsender!");  
5.     }  
6. }  

1. public class SmsSender implements Sender {  
2.   
3.     @Override  
4.     public void Send() {  
5.         System.out.println("this is sms sender!");  
6.     }  
7. }  

1. public class SendFactory {  
2.   
3.     public Sender produce(String type) {  
4.         if ("mail".equals(type)) {  
5.             return new MailSender();  
6.         } else if ("sms".equals(type)) {  
7.             return new SmsSender();  
8.         } else {  
9.             System.out.println("請輸入正確的型別!");  
10.             return null;  
11.         }  
12.     }  
13. }  

1. public class FactoryTest {  
2.   
3.     public static void main(String[] args) {  
4.         SendFactory factory = new SendFactory();  
5.         Sender sender = factory.produce("sms");  
6.         sender.Send();  
7.     }  
8. }  

1.         return new MailSender();  
2.     }  
3.       
4.     public Sender produceSms(){  
5.         return new SmsSender();  
6.     }  
7. }  

1. public class FactoryTest {  
2.   
3.     public static void main(String[] args) {  
4.         SendFactory factory = new SendFactory();  
5.         Sender sender = factory.produceMail();  
6.         sender.Send();  
7.     }  
8. }  

1. public class SendFactory {  
2.       
3.     public static Sender produceMail(){  
4.         return new MailSender();  
5.     }  
6.       
7.     public static Sender produceSms(){  
8.         return new SmsSender();  
9.     }  
10. }  

1. public class FactoryTest {  
2.   
3.     public static void main(String[] args) {      
4.         Sender sender = SendFactory.produceMail();  
5.         sender.Send();  
6.     }  
7. }  

1. public interface Sender {  
2.     public void Send();  
3. }  

1. public class MailSender implements Sender {  
2.     @Override  
3.     public void Send() {  
4.         System.out.println("this is mailsender!");  
5.     }  
6. }  

1. public class SmsSender implements Sender {  
2.   
3.     @Override  
4.     public void Send() {  
5.         System.out.println("this is sms sender!");  
6.     }  
7. }  

1. public class SendMailFactory implements Provider {  
2.       
3.     @Override  
4.     public Sender produce(){  
5.         return new MailSender();  
6.     }  
7. }  

1. public class SendSmsFactory implements Provider{  
2.   
3.     @Override  
4.     public Sender produce() {  
5.         return new SmsSender();  
6.     }  
7. }  

1. public interface Provider {  
2.     public Sender produce();  
3. }  

1. public class Test {  
2.   
3.     public static void main(String[] args) {  
4.         Provider provider = new SendMailFactory();  
5.         Sender sender = provider.produce();  
6.         sender.Send();  
7.     }  
8. }  

工廠方法模式：
一個抽象產品類，可以派生出多個具體產品類。   
一個抽象工廠類，可以派生出多個具體工廠類。   
每個具體工廠類只能建立一個具體產品類的例項。

抽象工廠模式：
多個抽象產品類，每個抽象產品類可以派生出多個具體產品類。   
一個抽象工廠類，可以派生出多個具體工廠類。   
每個具體工廠類可以建立多個具體產品類的例項，也就是建立的是一個產品線下的多個產品。   
    
區別：
工廠方法模式只有一個抽象產品類，而抽象工廠模式有多個。   
工廠方法模式的具體工廠類只能建立一個具體產品類的例項，而抽象工廠模式可以建立多個。

工廠方法建立 "一種" 產品，他的著重點在於"怎麼建立"，也就是說如果你開發，你的大量程式碼很可能圍繞著這種產品的構造，初始化這些細節上面。也因為如此，類似的產品之間有很多可以複用的特徵，所以會和模版方法相隨。 

抽象工廠需要建立一些列產品，著重點在於"建立哪些"產品上，也就是說，如果你開發，你的主要任務是劃分不同差異的產品線，並且儘量保持每條產品線介面一致，從而可以從同一個抽象工廠繼承。

對於java來說，你能見到的大部分抽象工廠模式都是這樣的：
---它的裡面是一堆工廠方法，每個工廠方法返回某種型別的物件。

比如說工廠可以生產滑鼠和鍵盤。那麼抽象工廠的實現類（它的某個具體子類）的物件都可以生產滑鼠和鍵盤，但可能工廠A生產的是羅技的鍵盤和滑鼠，工廠B是微軟的。

這樣A和B就是工廠，對應於抽象工廠；
每個工廠生產的滑鼠和鍵盤就是產品，對應於工廠方法；

用了工廠方法模式，你替換生成鍵盤的工廠方法，就可以把鍵盤從羅技換到微軟。但是用了抽象工廠模式，你只要換家工廠，就可以同時替換滑鼠和鍵盤一套。如果你要的產品有幾十個，當然用抽象工廠模式一次替換全部最方便（這個工廠會替你用相應的工廠方法）

所以說抽象工廠就像工廠，而工廠方法則像是工廠的一種產品生產線

1. public class Singleton {  
2.   
3.     /* 持有私有靜態例項，防止被引用，此處賦值為null，目的是實現延遲載入 */  
4.     private static Singleton instance = null;  
5.   
6.     /* 私有構造方法，防止被例項化 */  
7.     private Singleton() {  
8.     }  
9.   
10.     /* 靜態工程方法，建立例項 */  
11.     public static Singleton getInstance() {  
12.         if (instance == null) {  
13.             instance = new Singleton();  
14.         }  
15.         return instance;  
16.     }  
17.   
18.     /* 如果該物件被用於序列化，可以保證物件在序列化前後保持一致 */  
19.     public Object readResolve() {  
20.         return instance;  
21.     }  
22. }  

1. public static synchronized Singleton getInstance() {  
2.         if (instance == null) {  
3.             instance = new Singleton();  
4.         }  
5.         return instance;  
6.     }  

1. public static Singleton getInstance() {  
2.         if (instance == null) {  
3.             synchronized (instance) {  
4.                 if (instance == null) {  
5.                     instance = new Singleton();  
6.                 }  
7.             }  
8.         }  
9.         return instance;  
10.     }  

1. private static class SingletonFactory{           
2.         private static Singleton instance = new Singleton();           
3.     }           
4.     public static Singleton getInstance(){           
5.         return SingletonFactory.instance;           
6.     }   

1. public class Singleton {  
2.   
3.     /* 私有構造方法，防止被例項化 */  
4.     private Singleton() {  
5.     }  
6.   
7.     /* 此處使用一個內部類來維護單例 */  
8.     private static class SingletonFactory {  
9.         private static Singleton instance = new Singleton();  
10.     }  
11.   
12.     /* 獲取例項 */  
13.     public static Singleton getInstance() {  
14.         return SingletonFactory.instance;  
15.     }  
16.   
17.     /* 如果該物件被用於序列化，可以保證物件在序列化前後保持一致 */  
18.     public Object readResolve() {  
19.         return getInstance();  
20.     }  
21. }  

1. public class SingletonTest {  
2.   
3.     private static SingletonTest instance = null;  
4.   
5.     private SingletonTest() {  
6.     }  
7.   
8.     private static synchronized void syncInit() {  
9.         if (instance == null) {  
10.             instance = new SingletonTest();  
11.         }  
12.     }  
13.   
14.     public static SingletonTest getInstance() {  
15.         if (instance == null) {  
16.             syncInit();  
17.         }  
18.         return instance;  
19.     }  
20. }  

1. public class SingletonTest {  
2.   
3.     private static SingletonTest instance = null;  
4.     private Vector properties = null;  
5.   
6.     public Vector getProperties() {  
7.         return properties;  
8.     }  
9.   
10.     private SingletonTest() {  
11.     }  
12.   
13.     private static synchronized void syncInit() {  
14.         if (instance == null) {  
15.             instance = new SingletonTest();  
16.         }  
17.     }  
18.   
19.     public static SingletonTest getInstance() {  
20.         if (instance == null) {  
21.             syncInit();  
22.         }  
23.         return instance;  
24.     }  
25.   
26.     public void updateProperties() {  
27.         SingletonTest shadow = new SingletonTest();  
28.         properties = shadow.getProperties();  
29.     }  
30. }  

1. public class Prototype implements Cloneable {  
2.   
3.     public Object clone() throws CloneNotSupportedException {  
4.         Prototype proto = (Prototype) super.clone();  
5.         return proto;  
6.     }  
7. }  

1. public class Prototype implements Cloneable, Serializable {  
2.   
3.     private static final long serialVersionUID = 1L;  
4.     private String string;  
5.   
6.     private SerializableObject obj;  
7.   
8.     /* 淺複製 */  
9.     public Object clone() throws CloneNotSupportedException {  
10.         Prototype proto = (Prototype) super.clone();  
11.         return proto;  
12.     }  
13.   
14.     /* 深複製 */  
15.     public Object deepClone() throws IOException, ClassNotFoundException {  
16.   
17.         /* 寫入當前物件的二進位制流 */  
18.         ByteArrayOutputStream bos = new ByteArrayOutputStream();  
19.         ObjectOutputStream oos = new ObjectOutputStream(bos);  
20.         oos.writeObject(this);  
21.   
22.         /* 讀出二進位制流產生的新物件 */  
23.         ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());  
24.         ObjectInputStream ois = new ObjectInputStream(bis);  
25.         return ois.readObject();  
26.     }  
27.   
28.     public String getString() {  
29.         return string;  
30.     }  
31.   
32.     public void setString(String string) {  
33.         this.string = string;  
34.     }  
35.   
36.     public SerializableObject getObj() {  
37.         return obj;  
38.     }  
39.   
40.     public void setObj(SerializableObject obj) {  
41.         this.obj = obj;  
42.     }  
43.   
44. }  
45.   
46. class SerializableObject implements Serializable {  
47.     private static final long serialVersionUID = 1L;  
48. }  

 

要實現深複製，需要採用流的形式讀入當前物件的二進位制輸入，再寫出二進位制資料對應的物件。

我們接著討論設計模式，上篇文章我講完了5種建立型模式，這章開始，我將講下7種結構型模式：介面卡模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。其中物件的介面卡模式是各種模式的起源，我們看下面的圖：

6、介面卡模式

 介面卡模式將某個類的介面轉換成客戶端期望的另一個介面表示，目的是消除由於介面不匹配所造成的類的相容性問題。主要分為三類：類的介面卡模式、物件的介面卡模式、介面的介面卡模式。

01、類的介面卡模式

核心思想就是：有一個Source類，擁有一個方法，待適配，目標介面是Targetable，通過Adapter類，將Source的功能擴充套件到Targetable裡，看程式碼：

Adapter類繼承Source類，實現Targetable介面，下面是測試類：

輸出：

this is original method!
this is the targetable method!

這樣Targetable介面的實現類就具有了Source類的功能。

02、物件的介面卡模式

基本思路和類的介面卡模式相同，只是將Adapter類作修改，這次不繼承Source類，而是持有Source類的例項，以達到解決相容性的問題。看圖：

 

只需要修改Adapter類的原始碼即可：

測試類：

輸出與第一種一樣，只是適配的方法不同而已。

03、介面的介面卡模式

第三種介面卡模式是介面的介面卡模式，介面的介面卡是這樣的：有時我們寫的一個介面中有多個抽象方法，當我們寫該介面的實現類時，必須實現該介面的所有方法，這明顯有時比較浪費，因為並不是所有的方法都是我們需要的，有時只需要某一些，此處為了解決這個問題，我們引入了介面的介面卡模式，藉助於一個抽象類，該抽象類實現了該介面，實現了所有的方法，而我們不和原始的介面打交道，只和該抽象類取得聯絡，所以我們寫一個類，繼承該抽象類，重寫我們需要的方法就行。看一下類圖：

這個很好理解，在實際開發中，我們也常會遇到這種介面中定義了太多的方法，以致於有時我們在一些實現類中並不是都需要。看程式碼：

抽象類Wrapper2：

測試輸出：

the sourceable interface's first Sub1!
the sourceable interface's second Sub2!

達到了我們的效果！

 講了這麼多，總結一下三種介面卡模式的應用場景：

類的介面卡模式：當希望將一個類轉換成滿足另一個新介面的類時，可以使用類的介面卡模式，建立一個新類，繼承原有的類，實現新的介面即可。

物件的介面卡模式：當希望將一個物件轉換成滿足另一個新介面的物件時，可以建立一個Wrapper類，持有原類的一個例項，在Wrapper類的方法中，呼叫例項的方法就行。

介面的介面卡模式：當不希望實現一個介面中所有的方法時，可以建立一個抽象類Wrapper，實現所有方法，我們寫別的類的時候，繼承抽象類即可。

7、裝飾模式（Decorator）

顧名思義，裝飾模式就是給一個物件增加一些新的功能，而且是動態的，要求裝飾物件和被裝飾物件實現同一個介面，裝飾物件持有被裝飾物件的例項，關係圖如下：

Source類是被裝飾類，Decorator類是一個裝飾類，可以為Source類動態的新增一些功能，程式碼如下：

測試類：

輸出：

before decorator!
the original method!
after decorator!

裝飾器模式的應用場景：

1、需要擴充套件一個類的功能。

2、動態的為一個物件增加功能，而且還能動態撤銷。（繼承不能做到這一點，繼承的功能是靜態的，不能動態增刪。）

缺點：產生過多相似的物件，不易排錯！

8、代理模式（Proxy）

其實每個模式名稱就表明了該模式的作用，代理模式就是多一個代理類出來，替原物件進行一些操作，比如我們在租房子的時候回去找中介，為什麼呢？因為你對該地區房屋的資訊掌握的不夠全面，希望找一個更熟悉的人去幫你做，此處的代理就是這個意思。再如我們有的時候打官司，我們需要請律師，因為律師在法律方面有專長，可以替我們進行操作，表達我們的想法。先來看看關係圖：

 

根據上文的闡述，代理模式就比較容易的理解了，我們看下程式碼：

測試類：

輸出：

before proxy!
the original method!
after proxy!

代理模式的應用場景：

如果已有的方法在使用的時候需要對原有的方法進行改進，此時有兩種辦法：

1、修改原有的方法來適應。這樣違反了“對擴充套件開放，對修改關閉”的原則。

2、就是採用一個代理類呼叫原有的方法，且對產生的結果進行控制。這種方法就是代理模式。

使用代理模式，可以將功能劃分的更加清晰，有助於後期維護！

9、外觀模式（Facade）

外觀模式是為了解決類與類之家的依賴關係的，像spring一樣，可以將類和類之間的關係配置到配置檔案中，而外觀模式就是將他們的關係放在一個Facade類中，降低了類類之間的耦合度，該模式中沒有涉及到介面，看下類圖：（我們以一個計算機的啟動過程為例）

我們先看下實現類：

User類如下：

輸出：

start the computer!
cpu startup!
memory startup!
disk startup!
start computer finished!
begin to close the computer!
cpu shutdown!
memory shutdown!
disk shutdown!
computer closed!

如果我們沒有Computer類，那麼，CPU、Memory、Disk他們之間將會相互持有例項，產生關係，這樣會造成嚴重的依賴，修改一個類，可能會帶來其他類的修改，這不是我們想要看到的，有了Computer類，他們之間的關係被放在了Computer類裡，這樣就起到了解耦的作用，這，就是外觀模式！

10、橋接模式（Bridge）

橋接模式就是把事物和其具體實現分開，使他們可以各自獨立的變化。橋接的用意是：將抽象化與實現化解耦，使得二者可以獨立變化，像我們常用的JDBC橋DriverManager一樣，JDBC進行連線資料庫的時候，在各個資料庫之間進行切換，基本不需要動太多的程式碼，甚至絲毫不用動，原因就是JDBC提供統一介面，每個資料庫提供各自的實現，用一個叫做資料庫驅動的程式來橋接就行了。我們來看看關係圖：

實現程式碼：

先定義介面：

分別定義兩個實現類：

定義一個橋，持有Sourceable的一個例項：

測試類：

output：

this is the first sub!
this is the second sub!

這樣，就通過對Bridge類的呼叫，實現了對介面Sourceable的實現類SourceSub1和SourceSub2的呼叫。接下來我再畫個圖，大家就應該明白了，因為這個圖是我們JDBC連線的原理，有資料庫學習基礎的，一結合就都懂了。

11、組合模式（Composite）

組合模式有時又叫部分-整體模式在處理類似樹形結構的問題時比較方便，看看關係圖：

直接來看程式碼：

使用場景：將多個物件組合在一起進行操作，常用於表示樹形結構中，例如二叉樹，數等。

12、享元模式（Flyweight）

享元模式的主要目的是實現物件的共享，即共享池，當系統中物件多的時候可以減少記憶體的開銷，通常與工廠模式一起使用。

FlyWeightFactory負責建立和管理享元單元，當一個客戶端請求時，工廠需要檢查當前物件池中是否有符合條件的物件，如果有，就返回已經存在的物件，如果沒有，則建立一個新物件，FlyWeight是超類。一提到共享池，我們很容易聯想到Java裡面的JDBC連線池，想想每個連線的特點，我們不難總結出：適用於作共享的一些個物件，他們有一些共有的屬性，就拿資料庫連線池來說，url、driverClassName、username、password及dbname，這些屬性對於每個連線來說都是一樣的，所以就適合用享元模式來處理，建一個工廠類，將上述類似屬性作為內部資料，其它的作為外部資料，在方法呼叫時，當做引數傳進來，這樣就節省了空間，減少了例項的數量。

看個例子：

看下資料庫連線池的程式碼：

 

 C、關係模式（11種）

先來張圖，看看這11中模式的關係：

第一類：通過父類與子類的關係進行實現。

第二類：兩個類之間。

第三類：類的狀態。

第四類：通過中間類

父類與子類關係

13、策略模式（strategy）

策略模式定義了一系列演算法，並將每個演算法封裝起來，使他們可以相互替換，且演算法的變化不會影響到使用演算法的客戶。需要設計一個介面，為一系列實現類提供統一的方法，多個實現類實現該介面，設計一個抽象類（可有可無，屬於輔助類），提供輔助函式，關係圖如下：

圖中ICalculator提供同意的方法，
AbstractCalculator是輔助類，提供輔助方法，接下來，依次實現下每個類：

首先統一介面：

輔助類：

三個實現類：

簡單的測試類：

輸出：10

策略模式的決定權在使用者，系統本身提供不同演算法的實現，新增或者刪除演算法，對各種演算法做封裝。因此，策略模式多用在演算法決策系統中，外部使用者只需要決定用哪個演算法即可。

14、模板方法模式（Template Method）

解釋一下模板方法模式，就是指：一個抽象類中，有一個主方法，再定義1...n個方法，可以是抽象的，也可以是實際的方法，定義一個類，繼承該抽象類，重寫抽象方法，通過呼叫抽象類，實現對子類的呼叫，先看個關係圖：

就是在AbstractCalculator類中定義一個主方法calculate，calculate()呼叫spilt()等，Plus和Minus分別繼承AbstractCalculator類，通過對AbstractCalculator的呼叫實現對子類的呼叫，看下面的例子：

測試類：

我跟蹤下這個小程式的執行過程：首先將exp和"\\+"做引數，呼叫AbstractCalculator類裡的calculate(String,String)方法，在calculate(String,String)裡呼叫同類的split()，之後再呼叫calculate(int ,int)方法，從這個方法進入到子類中，執行完return num1 + num2後，將值返回到AbstractCalculator類，賦給result，列印出來。正好驗證了我們開頭的思路。

類之間的關係

15、觀察者模式（Observer）

包括這個模式在內的接下來的四個模式，都是類和類之間的關係，不涉及到繼承，學的時候應該 記得歸納，記得本文最開始的那個圖。觀察者模式很好理解，類似於郵件訂閱和RSS訂閱，當我們瀏覽一些部落格或wiki時，經常會看到RSS圖示，就這的意思是，當你訂閱了該文章，如果後續有更新，會及時通知你。其實，簡單來講就一句話：當一個物件變化時，其它依賴該物件的物件都會收到通知，並且隨著變化！物件之間是一種一對多的關係。先來看看關係圖：

我解釋下這些類的作用：MySubject類就是我們的主物件，Observer1和Observer2是依賴於MySubject的物件，當MySubject變化時，Observer1和Observer2必然變化。AbstractSubject類中定義著需要監控的物件列表，可以對其進行修改：增加或刪除被監控物件，且當MySubject變化時，負責通知在列表記憶體在的物件。我們看實現程式碼：

一個Observer介面：

兩個實現類：

Subject介面及實現類：

測試類：

輸出：

update self!
observer1 has received!
observer2 has received!

 這些東西，其實不難，只是有些抽象，不太容易整體理解，建議讀者：根據關係圖，新建專案，自己寫程式碼（或者參考我的程式碼）,按照總體思路走一遍，這樣才能體會它的思想，理解起來容易！

16、迭代子模式（Iterator）

顧名思義，迭代器模式就是順序訪問聚集中的物件，一般來說，集合中非常常見，如果對集合類比較熟悉的話，理解本模式會十分輕鬆。這句話包含兩層意思：一是需要遍歷的物件，即聚集物件，二是迭代器物件，用於對聚集物件進行遍歷訪問。我們看下關係圖：

 

這個思路和我們常用的一模一樣，MyCollection中定義了集合的一些操作，MyIterator中定義了一系列迭代操作，且持有Collection例項，我們來看看實現程式碼：

兩個介面：

兩個實現：

測試類：

輸出：A B C D E

此處我們貌似模擬了一個集合類的過程，感覺是不是很爽？其實JDK中各個類也都是這些基本的東西，加一些設計模式，再加一些優化放到一起的，只要我們把這些東西學會了，掌握好了，我們也可以寫出自己的集合類，甚至框架！

17、責任鏈模式（Chain of Responsibility）

接下來我們將要談談責任鏈模式，有多個物件，每個物件持有對下一個物件的引用，這樣就會形成一條鏈，請求在這條鏈上傳遞，直到某一物件決定處理該請求。但是發出者並不清楚到底最終那個物件會處理該請求，所以，責任鏈模式可以實現，在隱瞞客戶端的情況下，對系統進行動態的調整。先看看關係圖：

 

 

Abstracthandler類提供了get和set方法，方便MyHandle類設定和修改引用物件，MyHandle類是核心，例項化後生成一系列相互持有的物件，構成一條鏈。

輸出：

h1deal!
h2deal!
h3deal!

此處強調一點就是，連結上的請求可以是一條鏈，可以是一個樹，還可以是一個環，模式本身不約束這個，需要我們自己去實現，同時，在一個時刻，命令只允許由一個物件傳給另一個物件，而不允許傳給多個物件。

 18、命令模式（Command）

命令模式很好理解，舉個例子，司令員下令讓士兵去幹件事情，從整個事情的角度來考慮，司令員的作用是，發出口令，口令經過傳遞，傳到了士兵耳朵裡，士兵去執行。這個過程好在，三者相互解耦，任何一方都不用去依賴其他人，只需要做好自己的事兒就行，司令員要的是結果，不會去關注到底士兵是怎麼實現的。我們看看關係圖：

Invoker是呼叫者（司令員），Receiver是被呼叫者（士兵），MyCommand是命令，實現了Command介面，持有接收物件，看實現程式碼：

輸出：command received!

這個很哈理解，命令模式的目的就是達到命令的發出者和執行者之間解耦，實現請求和執行分開，熟悉Struts的同學應該知道，Struts其實就是一種將請求和呈現分離的技術，其中必然涉及命令模式的思想！

其實每個設計模式都是很重要的一種思想，看上去很熟，其實是因為我們在學到的東西中都有涉及，儘管有時我們並不知道，其實在Java本身的設計之中處處都有體現，像AWT、JDBC、集合類、IO管道或者是Web框架，裡面設計模式無處不在。因為我們篇幅有限，很難講每一個設計模式都講的很詳細，不過我會盡我所能，儘量在有限的空間和篇幅內，把意思寫清楚了，更好讓大家明白。本章不出意外的話，應該是設計模式最後一講了，首先還是上一下上篇開頭的那個圖：

本章講講第三類和第四類。

類的狀態

19、備忘錄模式（Memento）

主要目的是儲存一個物件的某個狀態，以便在適當的時候恢復物件，個人覺得叫備份模式更形象些，通俗的講下：假設有原始類A，A中有各種屬性，A可以決定需要備份的屬性，備忘錄類B是用來儲存A的一些內部狀態，類C呢，就是一個用來儲存備忘錄的，且只能儲存，不能修改等操作。做個圖來分析一下：

Original類是原始類，裡面有需要儲存的屬性value及建立一個備忘錄類，用來儲存value值。Memento類是備忘錄類，Storage類是儲存備忘錄的類，持有Memento類的例項，該模式很好理解。直接看原始碼：

測試類：

輸出：

初始化狀態為：egg
修改後的狀態為：niu
恢復後的狀態為：egg

簡單描述下：新建原始類時，value被初始化為egg，後經過修改，將value的值置為niu，最後倒數第二行進行恢復狀態，結果成功恢復了。其實我覺得這個模式叫“備份-恢復”模式最形象。

20、狀態模式（State）

核心思想就是：當物件的狀態改變時，同時改變其行為，很好理解！就拿QQ來說，有幾種狀態，線上、隱身、忙碌等，每個狀態對應不同的操作，而且你的好友也能看到你的狀態，所以，狀態模式就兩點：1、可以通過改變狀態來獲得不同的行為。2、你的好友能同時看到你的變化。看圖：

State類是個狀態類，Context類可以實現切換，我們來看看程式碼：

 

測試類： 輸出：

 

execute the first opt!
execute the second opt!

根據這個特性，狀態模式在日常開發中用的挺多的，尤其是做網站的時候，我們有時希望根據物件的某一屬性，區別開他們的一些功能，比如說簡單的許可權控制等。

通過中間類

21、訪問者模式（Visitor）

訪問者模式把資料結構和作用於結構上的操作解耦合，使得操作集合可相對自由地演化。訪問者模式適用於資料結構相對穩定演算法又易變化的系統。因為訪問者模式使得演算法操作增加變得容易。若系統資料結構物件易於變化，經常有新的資料物件增加進來，則不適合使用訪問者模式。訪問者模式的優點是增加操作很容易，因為增加操作意味著增加新的訪問者。訪問者模式將有關行為集中到一個訪問者物件中，其改變不影響系統資料結構。其缺點就是增加新的資料結構很困難。—— From 百科

簡單來說，訪問者模式就是一種分離物件資料結構與行為的方法，通過這種分離，可達到為一個被訪問者動態新增新的操作而無需做其它的修改的效果。簡單關係圖：

來看看原碼：一個Visitor類，存放要訪問的物件，

 

Subject類，accept方法，接受將要訪問它的物件，getSubject()獲取將要被訪問的屬性，
測試： 輸出：visit the subject：love

該模式適用場景：如果我們想為一個現有的類增加新功能，不得不考慮幾個事情：1、新功能會不會與現有功能出現相容性問題？2、以後會不會再需要新增？3、如果類不允許修改程式碼怎麼辦？面對這些問題，最好的解決方法就是使用訪問者模式，訪問者模式適用於資料結構相對穩定的系統，把資料結構和演算法解耦，

22、中介者模式（Mediator）

中介者模式也是用來降低類類之間的耦合的，因為如果類類之間有依賴關係的話，不利於功能的擴充和維護，因為只要修改一個物件，其它關聯的物件都得進行修改。如果使用中介者模式，只需關心和Mediator類的關係，具體類類之間的關係及排程交給Mediator就行，這有點像spring容器的作用。先看看圖：

User類統一介面，User1和User2分別是不同的物件，二者之間有關聯，如果不採用中介者模式，則需要二者相互持有引用，這樣二者的耦合度很高，為了解耦，引入了Mediator類，提供統一介面，MyMediator為其實現類，裡面持有User1和User2的例項，用來實現對User1和User2的控制。這樣User1和User2兩個物件相互獨立，他們只需要保持好和Mediator之間的關係就行，剩下的全由MyMediator類來維護！基本實現：

 

測試類： 輸出：

user1 exe!
user2 exe!

23、直譯器模式（Interpreter）

直譯器模式是我們暫時的最後一講，一般主要應用在OOP開發中的編譯器的開發中，所以適用面比較窄。

Context類是一個上下文環境類，Plus和Minus分別是用來計算的實現，程式碼如下：

 

最後輸出正確的結果：3。

基本就這樣，直譯器模式用來做各種各樣的直譯器，如正規表示式等的直譯器等等！