23種設計模式全解析

一、設計模式的分類

總體來說設計模式分為三大類：

建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。

其實還有兩類：併發型模式和執行緒池模式。用一個圖片來整體描述一下：

二、設計模式的六大原則

總原則：開閉原則（Open Close Principle）

開閉原則就是說對擴充套件開放，對修改關閉。在程式需要進行拓展的時候，不能去修改原有的程式碼，而是要擴充套件原有程式碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程式的擴充套件性好，易於維護和升級。想要達到這樣的效果，我們需要使用介面和抽象類等，後面的具體設計中我們會提到這點。

1、單一職責原則

不要存在多於一個導致類變更的原因，也就是說每個類應該實現單一的職責，如若不然，就應該把類拆分。

2、里氏替換原則（Liskov Substitution Principle）

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

歷史替換原則中，子類對父類的方法儘量不要重寫和過載。因為父類代表了定義好的結構，通過這個規範的介面與外界互動，子類不應該隨便破壞它。

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

這個是開閉原則的基礎，具體內容：面向介面程式設計，依賴於抽象而不依賴於具體。寫程式碼時用到具體類時，不與具體類互動，而與具體類的上層介面互動。

4、介面隔離原則（Interface Segregation Principle）

這個原則的意思是：每個介面中不存在子類用不到卻必須實現的方法，如果不然，就要將介面拆分。使用多個隔離的介面，比使用單個介面（多個介面方法集合到一個的介面）要好。

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

就是說：一個類對自己依賴的類知道的越少越好。也就是說無論被依賴的類多麼複雜，都應該將邏輯封裝在方法的內部，通過public方法提供給外部。這樣當被依賴的類變化時，才能最小的影響該類。

最少知道原則的另一個表達方式是：只與直接的朋友通訊。類之間只要有耦合關係，就叫朋友關係。耦合分為依賴、關聯、聚合、組合等。我們稱出現為成員變數、方法引數、方法返回值中的類為直接朋友。區域性變數、臨時變數則不是直接的朋友。我們要求陌生的類不要作為區域性變量出現在類中。

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

原則是儘量首先使用合成/聚合的方式，而不是使用繼承。

三、Java的23中設計模式

A、建立模式

從這一塊開始，我們詳細介紹Java中23種設計模式的概念，應用場景等情況，並結合他們的特點及設計模式的原則進行分析。

首先，簡單工廠模式不屬於23中涉及模式，簡單工廠一般分為：普通簡單工廠、多方法簡單工廠、靜態方法簡單工廠。

0、簡單工廠模式

簡單工廠模式模式分為三種：

01、普通

就是建立一個工廠類，對實現了同一介面的一些類進行例項的建立。首先看下關係圖：

舉例如下：（我們舉一個傳送郵件和簡訊的例子）

首先，建立二者的共同介面：

public interface Sender {
public void Send();
}

其次，建立實現類：

public class MailSender implements Sender {
@Override
public void Send() {
System.out.println("this is mailsender!");
}
}

public class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("this is sms sender!");
}
}

最後，建工廠類：

public class SendFactory {
public Sender produce(String type) {
if ("mail".equals(type)) {
return new MailSender();
} else if ("sms".equals(type)) {
return new SmsSender();
} else {
System.out.println("請輸入正確的型別!");
return null;
}
}
}

我們來測試下：

public class FactoryTest {
public static void main(String[] args) {
SendFactory factory = new SendFactory();
Sender sender = factory.produce("sms");
sender.Send();
}
}

輸出：this is sms sender!

02、多個方法

是對普通工廠方法模式的改進，在普通工廠方法模式中，如果傳遞的字串出錯，則不能正確建立物件，而多個工廠方法模式是提供多個工廠方法，分別建立物件。關係圖：

將上面的程式碼做下修改，改動下SendFactory類就行，如下：

[java] view plain copypublic class SendFactory {

public Sender produceMail(){

return new MailSender();
}
public Sender produceSms(){
return new SmsSender();
}
}

測試類如下：

public class FactoryTest {
public static void main(String[] args) {
SendFactory factory = new SendFactory();
Sender sender = factory.produceMail();
sender.Send();
}
}

輸出：this is mailsender!

03、多個靜態方法

將上面的多個工廠方法模式裡的方法置為靜態的，不需要建立例項，直接呼叫即可。

public class SendFactory {
public static Sender produceMail(){
return new MailSender();
}
public static Sender produceSms(){
return new SmsSender();
}
}

public class FactoryTest {
public static void main(String[] args) {
Sender sender = SendFactory.produceMail();
sender.Send();
}
}

輸出：this is mailsender!

總體來說，工廠模式適合：凡是出現了大量的產品需要建立，並且具有共同的介面時，可以通過工廠方法模式進行建立。在以上的三種模式中，第一種如果傳入的字串有誤，不能正確建立物件，第三種相對於第二種，不需要例項化工廠類，所以，大多數情況下，我們會選用第三種——靜態工廠方法模式。

1、工廠方法模式（Factory Method）

簡單工廠模式有一個問題就是，類的建立依賴工廠類，也就是說，如果想要拓展程式，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，如何解決？就用到工廠方法模式，建立一個工廠介面和建立多個工廠實現類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的程式碼。

請看例子：

public interface Sender {
public void Send();
}

兩個實現類：

public class MailSender implements Sender {
@Override
public void Send() {
System.out.println("this is mailsender!");
}
}

public class SmsSender implements Sender {
@Override
public void Send() {
System.out.println("this is sms sender!");
}
}

兩個工廠類：

public class SendMailFactory implements Provider {
@Override
public Sender produce(){
return new MailSender();
}
}

public class SendSmsFactory implements Provider{
@Override
public Sender produce() {
return new SmsSender();
}
}

在提供一個介面：

public interface Provider {
public Sender produce();
}

測試類：

public class Test {
public static void main(String[] args) {
Provider provider = new SendMailFactory();
Sender sender = provider.produce();
sender.Send();
}
}

其實這個模式的好處就是，如果你現在想增加一個功能：發及時資訊，則只需做一個實現類，實現Sender介面，同時做一個工廠類，實現Provider介面，就OK了，無需去改動現成的程式碼。這樣做，拓展性較好！

2、抽象工廠模式

工廠方法模式和抽象工廠模式不好分清楚，他們的區別如下：

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

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

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

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

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

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

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

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

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

3、單例模式（Singleton）

單例物件（Singleton）是一種常用的設計模式。在Java應用中，單例物件能保證在一個JVM中，該物件只有一個例項存在。這樣的模式有幾個好處：

1、某些類建立比較頻繁，對於一些大型的物件，這是一筆很大的系統開銷。

2、省去了new操作符，降低了系統記憶體的使用頻率，減輕GC壓力。

3、有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以建立多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易伺服器獨立控制整個流程。

首先我們寫一個簡單的單例類：

public class Singleton {
/* 持有私有靜態例項，防止被引用，此處賦值為null，目的是實現延遲載入 */
private static Singleton instance = null;
/* 私有構造方法，防止被例項化 */
private Singleton() {
}
/* 靜態工程方法，建立例項 */
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
/* 如果該物件被用於序列化，可以保證物件在序列化前後保持一致 */
public Object readResolve() {
return instance;
}
}

這個類可以滿足基本要求，但是，像這樣毫無執行緒安全保護的類，如果我們把它放入多執行緒的環境下，肯定就會出現問題了，如何解決？我們首先會想到對getInstance方法加synchronized關鍵字，如下：

public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}

但是，synchronized關鍵字鎖住的是這個物件，這樣的用法，在效能上會有所下降，因為每次呼叫getInstance()，都要對物件上鎖，事實上，只有在第一次建立物件的時候需要加鎖，之後就不需要了，所以，這個地方需要改進。我們改成下面這個：

public static Singleton getInstance() {
if (instance == null) {
synchronized (instance) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}

似乎解決了之前提到的問題，將synchronized關鍵字加在了內部，也就是說當呼叫的時候是不需要加鎖的，只有在instance為null，並建立物件的時候才需要加鎖，效能有一定的提升。但是，這樣的情況，還是有可能有問題的，看下面的情況：在Java指令中建立物件和賦值操作是分開進行的，也就是說instance = new Singleton();語句是分兩步執行的。但是JVM並不保證這兩個操作的先後順序，也就是說有可能JVM會為新的Singleton例項分配空間，然後直接賦值給instance成員，然後再去初始化這個Singleton例項。這樣就可能出錯了，我們以A、B兩個執行緒為例：

a>A、B執行緒同時進入了第一個if判斷

b>A首先進入synchronized塊，由於instance為null，所以它執行instance = new Singleton();

c>由於JVM內部的優化機制，JVM先畫出了一些分配給Singleton例項的空白記憶體，並賦值給instance成員（注意此時JVM沒有開始初始化這個例項），然後A離開了synchronized塊。

d>B進入synchronized塊，由於instance此時不是null，因此它馬上離開了synchronized塊並將結果返回給呼叫該方法的程式。

e>此時B執行緒打算使用Singleton例項，卻發現它沒有被初始化，於是錯誤發生了。

所以程式還是有可能發生錯誤，其實程式在執行過程是很複雜的，從這點我們就可以看出，尤其是在寫多執行緒環境下的程式更有難度，有挑戰性。我們對該程式做進一步優化：

private static class SingletonFactory{
private static Singleton instance = new Singleton();
}
public static Singleton getInstance(){
return SingletonFactory.instance;
}

實際情況是，單例模式使用內部類來維護單例的實現，JVM內部的機制能夠保證當一個類被載入的時候，這個類的載入過程是執行緒互斥的。這樣當我們第一次呼叫getInstance的時候，JVM能夠幫我們保證instance只被建立一次，並且會保證把賦值給instance的記憶體初始化完畢，這樣我們就不用擔心上面的問題。同時該方法也只會在第一次呼叫的時候使用互斥機制，這樣就解決了低效能問題。這樣我們暫時總結一個完美的單例模式：

public class Singleton {
/* 私有構造方法，防止被例項化 */
private Singleton() {
}
/* 此處使用一個內部類來維護單例 */
private static class SingletonFactory {
private static Singleton instance = new Singleton();
}
/* 獲取例項 */
public static Singleton getInstance() {
return SingletonFactory.instance;
}
/* 如果該物件被用於序列化，可以保證物件在序列化前後保持一致 */
public Object readResolve() {
return getInstance();
}
}

其實說它完美，也不一定，如果在建構函式中丟擲異常，例項將永遠得不到建立，也會出錯。所以說，十分完美的東西是沒有的，我們只能根據實際情況，選擇最適合自己應用場景的實現方法。也有人這樣實現：因為我們只需要在建立類的時候進行同步，所以只要將建立和getInstance()分開，單獨為建立加synchronized關鍵字，也是可以的：

public class SingletonTest {
private static SingletonTest instance = null;
private SingletonTest() {
}
private static synchronized void syncInit() {
if (instance == null) {
instance = new SingletonTest();
}
}
public static SingletonTest getInstance() {
if (instance == null) {
syncInit();
}
return instance;
}
}

考慮效能的話，整個程式只需建立一次例項，所以效能也不會有什麼影響。

補充：採用"影子例項"的辦法為單例物件的屬性同步更新

public class SingletonTest {
private static SingletonTest instance = null;
private Vector properties = null;
public Vector getProperties() {
return properties;
}
private SingletonTest() {
}
private static synchronized void syncInit() {
if (instance == null) {
instance = new SingletonTest();
}
}
public static SingletonTest getInstance() {
if (instance == null) {
syncInit();
}
return instance;
}
public void updateProperties() {
SingletonTest shadow = new SingletonTest();
properties = shadow.getProperties();
}
}

通過單例模式的學習告訴我們：

1、單例模式理解起來簡單，但是具體實現起來還是有一定的難度。

2、synchronized關鍵字鎖定的是物件，在用的時候，一定要在恰當的地方使用（注意需要使用鎖的物件和過程，可能有的時候並不是整個物件及整個過程都需要鎖）。

到這兒，單例模式基本已經講完了，結尾處，筆者突然想到另一個問題，就是採用類的靜態方法，實現單例模式的效果，也是可行的，此處二者有什麼不同？

首先，靜態類不能實現介面。（從類的角度說是可以的，但是那樣就破壞了靜態了。因為介面中不允許有static修飾的方法，所以即使實現了也是非靜態的）

其次，單例可以被延遲初始化，靜態類一般在第一次載入是初始化。之所以延遲載入，是因為有些類比較龐大，所以延遲載入有助於提升效能。

再次，單例類可以被繼承，他的方法可以被覆寫。但是靜態類內部方法都是static，無法被覆寫。

最後一點，單例類比較靈活，畢竟從實現上只是一個普通的Java類，只要滿足單例的基本需求，你可以在裡面隨心所欲的實現一些其它功能，但是靜態類不行。從上面這些概括中，基本可以看出二者的區別，但是，從另一方面講，我們上面最後實現的那個單例模式，內部就是用一個靜態類來實現的，所以，二者有很大的關聯，只是我們考慮問題的層面不同罷了。兩種思想的結合，才能造就出完美的解決方案，就像HashMap採用陣列+連結串列來實現一樣，其實生活中很多事情都是這樣，單用不同的方法來處理問題，總是有優點也有缺點，最完美的方法是，結合各個方法的優點，才能最好的解決問題！

4、建造者模式（Builder）

5、原型模式（Prototype）

原型模式雖然是建立型的模式，但是與工程模式沒有關係，從名字即可看出，該模式的思想就是將一個物件作為原型，對其進行復制、克隆，產生一個和原物件類似的新物件。本小結會通過物件的複製，進行講解。在Java中，複製物件是通過clone()實現的，先建立一個原型類：

public class Prototype implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Prototype proto = (Prototype) super.clone();
return proto;
}
}

很簡單，一個原型類，只需要實現Cloneable介面，覆寫clone方法，此處clone方法可以改成任意的名稱，因為Cloneable介面是個空介面，你可以任意定義實現類的方法名，如cloneA或者cloneB，因為此處的重點是super.clone()這句話，super.clone()呼叫的是Object的clone()方法，而在Object類中，clone()是native的，具體怎麼實現，我會在另一篇文章中，關於解讀Java中本地方法的呼叫，此處不再深究。在這兒，我將結合物件的淺複製和深複製來說一下，首先需要了解物件深、淺複製的概念：

淺複製：將一個物件複製後，基本資料型別的變數都會重新建立，而引用型別，指向的還是原物件所指向的。

深複製：將一個物件複製後，不論是基本資料型別還有引用型別，都是重新建立的。簡單來說，就是深複製進行了完全徹底的複製，而淺複製不徹底。

此處，寫一個深淺複製的例子：

public class Prototype implements Cloneable, Serializable {
private static final long serialVersionUID = 1L;
private String string;
private SerializableObject obj;
/* 淺複製 */
public Object clone() throws CloneNotSupportedException {
Prototype proto = (Prototype) super.clone();
return proto;
}
/* 深複製 */
public Object deepClone() throws IOException, ClassNotFoundException {
/* 寫入當前物件的二進位制流 */
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(this);
/* 讀出二進位制流產生的新物件 */
ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bis);
return ois.readObject();
}
public String getString() {
return string;
}
public void setString(String string) {
this.string = string;
}
public SerializableObject getObj() {
return obj;
}
public void setObj(SerializableObject obj) {
this.obj = obj;
}
}
class SerializableObject implements Serializable {
private static final long serialVersionUID = 1L;
}

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

B、結構模式（7種）

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

6、介面卡模式

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

01、類的介面卡模式

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

public class Source {
public void method1() {
System.out.println("this is original method!");
}
}

public interface Targetable {
/* 與原類中的方法相同 */
public void method1();
/* 新類的方法 */
public void method2();
}

public class Adapter extends Source implements Targetable {
@Override
public void method2() {
System.out.println("this is the targetable method!");
}
}

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

public class AdapterTest {
public static void main(String[] args) {
Targetable target = new Adapter();
target.method1();
target.method2();
}
}

輸出：

this is original method!
this is the targetable method!

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

02、物件的介面卡模式

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

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

public class Wrapper implements Targetable {
private Source source;
public Wrapper(Source source){
super();
this.source = source;
}
@Override
public void method2() {
System.out.println("this is the targetable method!");
}
@Override
public void method1() {
source.method1();
}
}

測試類：

public class AdapterTest {
public static void main(String[] args) {
Source source = new Source();
Targetable target = new Wrapper(source);
target.method1();
target.method2();
}
}

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

03、介面的介面卡模式

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

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

public interface Sourceable {
public void method1();
public void method2();
}

抽象類Wrapper2：

public abstract class Wrapper2 implements Sourceable{
public void method1(){}
public void method2(){}
}

public class SourceSub1 extends Wrapper2 {
public void method1(){
System.out.println("the sourceable interface's first Sub1!");
}
}

public class SourceSub2 extends Wrapper2 {
public void method2(){
System.out.println("the sourceable interface's second Sub2!");
}
}

public class WrapperTest {
public static void main(String[] args) {
Sourceable source1 = new SourceSub1();
Sourceable source2 = new SourceSub2();
source1.method1();
source1.method2();
source2.method1();
source2.method2();
}
}

測試輸出：

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

達到了我們的效果！

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

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

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

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

7、裝飾模式（Decorator）

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

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

public interface Sourceable {
public void method();
}

public class Source implements Sourceable {
@Override
public void method() {
System.out.println("the original method!");
}
}

public class Decorator implements Sourceable {
private Sourceable source;
public Decorator(Sourceable source){
super();
this.source = source;
}
@Override
public void method() {
System.out.println("before decorator!");
source.method();
System.out.println("after decorator!");
}
}

測試類：

public class DecoratorTest {
public static void main(String[] args) {
Sourceable source = new Source();
Sourceable obj = new Decorator(source);
obj.method();
}
}

輸出：

before decorator!
the original method!
after decorator!

裝飾器模式的應用場景：

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

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

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

8、代理模式（Proxy）

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

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

public interface Sourceable {
public void method();
}

public class Source implements Sourceable {
@Override
public void method() {
System.out.println("the original method!");
}
}

public class Proxy implements Sourceable {
private Source source;
public Proxy(){
super();
this.source = new Source();
}
@Override
public void method() {
before();
source.method();
atfer();
}
private void atfer() {
System.out.println("after proxy!");
}
private void before() {
System.out.println("before proxy!");
}
}

測試類：

public class ProxyTest {
public static void main(String[] args) {
Sourceable source = new Proxy();
source.method();
}
}

輸出：

before proxy!
the original method!
after proxy!

代理模式的應用場景：

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

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

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

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

9、外觀模式（Facade）

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

我們先看下實現類：

public class CPU {
public void startup(){
System.out.println("cpu startup!");
}
public void shutdown(){
System.out.println("cpu shutdown!");
}
}

public class Memory {
public void startup(){
System.out.println("memory startup!");
}
public void shutdown(){
System.out.println("memory shutdown!");
}
}

public class Disk {
public void startup(){
System.out.println("disk startup!");
}
public void shutdown(){
System.out.println("disk shutdown!");
}
}

public class Computer {
private CPU cpu;
private Memory memory;
private Disk disk;
public Computer(){
cpu = new CPU();
memory = new Memory();
disk = new Disk();
}
public void startup(){
System.out.println("start the computer!");
cpu.startup();
memory.startup();
disk.startup();
System.out.println("start computer finished!");
}
public void shutdown(){
System.out.println("begin to close the computer!");
cpu.shutdown();
memory.shutdown();
disk.shutdown();
System.out.println("computer closed!");
}
}

User類如下：

public class User {
public static void main(String[] args) {
Computer computer = new Computer();
computer.startup();
computer.shutdown();
}
}

輸出：

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提供統一介面，每個資料庫提供各自的實現，用一個叫做資料庫驅動的程式來橋接就行了。我們來看看關係圖：

實現程式碼：

先定義介面：

public interface Sourceable {
public void method();
}

分別定義兩個實現類：

public class SourceSub1 implements Sourceable {
@Override
public void method() {
System.out.println("this is the first sub!");
}
}

public class SourceSub2 implements Sourceable {
@Override
public void method() {
System.out.println("this is the second sub!");
}
}

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

public abstract class Bridge {
private Sourceable source;
public void method(){
source.method();
}
public Sourceable getSource() {
return source;
}
public void setSource(Sourceable source) {
this.source = source;
}
}

public class MyBridge extends Bridge {
public void method(){
getSource().method();
}
}

測試類：

public class BridgeTest {
public static void main(String[] args) {
Bridge bridge = new MyBridge();
/*呼叫第一個物件*/
Sourceable source1 = new SourceSub1();
bridge.setSource(source1);
bridge.method();
/*呼叫第二個物件*/
Sourceable source2 = new SourceSub2();
bridge.setSource(source2);
bridge.method();
}
}

output：

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

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

11、組合模式（Composite）

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

直接來看程式碼：

public class TreeNode {
private String name;
private TreeNode parent;
private Vector<TreeNode> children = new Vector<TreeNode>();
public TreeNode(String name){
this.name = name;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public TreeNode getParent() {
return parent;
}
public void setParent(TreeNode parent) {
this.parent = parent;
}
//新增孩子節點
public void add(TreeNode node){
children.add(node);
}
//刪除孩子節點
public void remove(TreeNode node){
children.remove(node);
}
//取得孩子節點
public Enumeration<TreeNode> getChildren(){
return children.elements();
}
}

public class Tree {
TreeNode root = null;
public Tree(String name) {
root = new TreeNode(name);
}
public static void main(String[] args) {
Tree tree = new Tree("A");
TreeNode nodeB = new TreeNode("B");
TreeNode nodeC = new TreeNode("C");
nodeB.add(nodeC);
tree.root.add(nodeB);
System.out.println("build the tree finished!");
}
}

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

12、享元模式（Flyweight）

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

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

看個例子：

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

public class ConnectionPool {
private Vector<Connection> pool;
/*公有屬性*/
private String url = "jdbc:mysql://localhost:3306/test";
private String username = "root";
private String password = "root";
private String driverClassName = "com.mysql.jdbc.Driver";
private int poolSize = 100;
private static ConnectionPool instance = null;
Connection conn = null;
/*構造方法，做一些初始化工作*/
private ConnectionPool() {
pool = new Vector<Connection>(poolSize);
for (int i = 0; i < poolSize; i++) {
try {
Class.forName(driverClassName);
conn = DriverManager.getConnection(url, username, password);
pool.add(conn);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
/* 返回連線到連線池 */
public synchronized void release() {
pool.add(conn);
}
/* 返回連線池中的一個數據庫連線 */
public synchronized Connection getConnection() {
if (pool.size() > 0) {

相關推薦

23種設計模式全解析-- 設計模式看這一篇就夠了

一、設計模式的分類總體來說設計模式分為三大類：建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。行為型模式，共十一種：策

23種設計模式全解析

一、設計模式的分類總體來說設計模式分為三大類：建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。行為型模式，共十一種：策略模式、模板

23種設計模式全解析及五種常見的 PHP 設計模式

一、設計模式的分類總體來說設計模式分為三大類：建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。行為型模式，共十一種：策略模式、模板方

追MM與設計模式（23種設計模式巧妙解析，趣味理解）

建立型模式 1、FACTORY—追MM少不了請吃飯了，麥當勞的雞翅和肯德基的雞翅都是MM愛吃的東西，雖然口味有所不同，但不管你帶MM去麥當勞或肯德基，只管向服務員說“來四個雞翅”就行了。麥當勞和肯德基就是生產雞翅的Factory 工廠模式：客戶類和工廠類分開。消費者任何

設計模式23種全解析（5分鐘徹底瞭解23種設計模式）

一、設計模式的分類總體來說設計模式分為三大類：建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。行為型模式，共十一種：策略模式、模板

大牛的23種設計模式及程式碼實現全解析

一、設計模式的分類總體來說設計模式分為三大類：建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。行為型模式，共十一種：策略模式、模板

23種軟體設計模式全解析

一、設計模式的分類總體來說設計模式分為三大類：建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。行為型模式，共十一種：策略

java開發-23種設計模式之菜鳥解析1

java開發有23種設計模式，很多工齡沒那麼長的java開發程式設計師可能都不會特意去了解它們，其實它存在的意義不只是應對各種面試，而是在開發過程中簡化、邏輯化、分類化你的程式碼，讓你的程式碼可讀性更高，為你的開發帶來便利的東西。廢話不多說，開始正題首先大家要了解設計模式的分類，一般分為三個型

Java 之23種設計模式解析

4、建造者模式（Builder） 5、原型模式（Prototype）原型模式雖然是建立型的模式，但是與工程模式沒有關係，從名字即可看出，該模式的思想就是將一個物件作為原型，對其進行復制、克隆，產生一個和原物件類似的新物件。本小結會通過物件的複製，進行講解。在Java

一篇文章學會23種設計模式，你需要的全不在這裡

總體來說設計模式分為三大類：建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘

一篇文章學會23種設計模式，你需要的全不在這裡2

一篇文章學會23種設計模式，你需要的全不在這裡總體來說設計模式分為三大類：建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。結構型模式，共七種：介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。行為型模式，共十一種：策略模式、模板方法模式、

23種設計模式介紹以及單例模式的學習

單例模式餓漢式 23種設計模式 gof23 1、GOF23 設計模式總共分成創建型模式、結構型模式和行為型模式三種： a、創建型模式： - 單例模式、工廠模式、抽象工廠模式、建造者模式、原型模式 b、構建型模式： - 適配器模式、橋接模式、裝配模式、組合模式、建造者模

23種設計模式介紹（一）---- 創建型模式

接口 ret static 深復制 return 對象相互 object c png 由於設計模式篇幅比較大，如果在一篇文章講完所有的設計模式的話不利於閱讀。於是我把它分為三篇文章 23種設計模式介紹（一）---- 創建型模式 23種設計模式介紹（二）---- 結構型模

【Unity與23種設計模式】狀態模式（State）

unity public text 開始 sys 狀態模式改變 val 繼承定義： “讓一個對象的行為隨著內部狀態的改變而變化，而該對象也像是換了類一樣” 應用場景：角色AI：控制角色在不同狀態下的AI行為服務器連接狀態：開始連線、連線中、斷線等狀態關卡進

轉：23種設計模式的應用場景

橋模式 man 16px pop 表示 black strong art bstr 設計模式主要分三個類型:創建型、結構型和行為型。其中創建型有：一、Singleton，單例模式：保證一個類只有一個實例，並提供一個訪問它的全局訪問點；

【Unity3D與23種設計模式】建造者模式（Builder）

產出 private 一個 gof 行為並且 bstr reac 定義 GoF中定義： “將一個復雜的構建流程與它的對象表現分離出來，讓相同的構建流程可以產生不同的對象行為表現。” 建造者模式可以分為兩個步驟來實施： 1.將復雜的構建流程獨立出來，並將整個流程分成

23種設計模式中的叠代器模式

pos over arr imp @override 一個 next() int position 叠代器模式：提供一種方法順序訪問一個聚合對象中的各個對象。那麽如何提供一個方法順序呢？ public interface Iterator<T>{ 　　publ

23種設計模式中的訪問者模式

功能需求封裝改變擴展數據結構模式困難操作如果訪問者模式：對於一組對象，在不改變數據結構的前提下，增加作用於這些結構元素新的功能。適用於數據結構相對穩定，它把數據結構和作用於其上的操作解耦，使得操作集合可以相對自由地演化。優點：符合單一職責原則擴展性

23種設計模式中的原型模式

1-1 ... 實例代碼 sets each png 為什麽 .get protect 原型模式：通過復制現有實例來創建新的實例，無須知道相應類的信息。個人見解：在大量循環時，需要初始化對象，用原型模式能節省大量的初始化所花費的時間，值得一談的是淺復制和深復制淺復制：

java 23種設計模式

代理建造者學習 article 適配器 htm ava arc 叠代備註這是別人總結的本來想轉載可惜不會怎麽轉載（感謝）以下是學習過程中查詢的資料,別人總結的資料,比較容易理解(站在各位巨人的肩膀上,望博主勿究) 創建型抽象工廠模式 http://www.cnblo

23種設計模式全解析

一、設計模式的分類

二、設計模式的六大原則

總原則：開閉原則（Open Close Principle）

1、單一職責原則

2、里氏替換原則（Liskov Substitution Principle）

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

4、介面隔離原則（Interface Segregation Principle）

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

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

三、Java的23中設計模式

A、建立模式

0、簡單工廠模式

1、工廠方法模式（Factory Method）

2、抽象工廠模式

3、單例模式（Singleton）

4、建造者模式（Builder）

5、原型模式（Prototype）

B、結構模式（7種）

6、介面卡模式

7、裝飾模式（Decorator）

8、代理模式（Proxy）

9、外觀模式（Facade）

10、橋接模式（Bridge）

11、組合模式（Composite）

相關推薦