結構型模式： 裝飾者模式(Decorator Pattern)

一、設計模式的分類

(如果以前看過關于設計模式的分類的話，這部分可以忽略！)

經過很多大神的總結，目前Java中一共23種經典的設計模式！

按照目的，設計模式可以分為以下三種用途：

1.建立型模式：用來處理對象的建立過程

2.結構型模式：用來處理類或者對象的組合

3.行為型模式：用來對類或對象怎樣互動和怎樣配置設定職責進行描述

建立型模式用來處理對象的建立過程，主要包含以下5種設計模式：

 工廠方法模式（Factory Method Pattern）

 抽象工廠模式（Abstract Factory Pattern）

 建造者模式（Builder Pattern）

 原型模式（Prototype Pattern）

 單例模式（Singleton Pattern）

結構型模式用來處理類或者對象的組合，主要包含以下7種設計模式：

 擴充卡模式（Adapter Pattern）

 橋接模式（Bridge Pattern）

 組合模式（Composite Pattern）

 裝飾者模式（Decorator Pattern）

 外觀模式（Facade Pattern）

 享元模式（Flyweight Pattern）

 代理模式（Proxy Pattern）

行為型模式用來對類或對象怎樣互動和怎樣配置設定職責進行描述，主要包含以下11種設計模式：

 責任鍊模式（Chain of Responsibility Pattern）

 指令模式（Command Pattern

 解釋器模式（Interpreter Pattern）

 疊代器模式（Iterator Pattern）

 中介者模式（Mediator Pattern）

 備忘錄模式（Memento Pattern）

 觀察者模式（Observer Pattern）

 狀态模式（State Pattern）

 政策模式（Strategy Pattern）

 模闆方法模式（Template Method Pattern）

 通路者模式（Visitor Pattern） 

本篇文章主要為講解一下 裝飾者模式(Decorator Pattern)！

注：概念性的東西可以忽略不看，可以在看完例子以後再看概念，這樣更有利于了解！

二、裝飾着模式概述

(注：建議沒有看過裝飾者模式的朋友們，先看執行個體，然後再看枯燥的概念)

1、定義：

裝飾者模式：指在不必改變原類檔案和使用繼承的情況下，動态地擴充一個對象的功能。它是通過建立一個包裝對象，也就是裝飾來包裹真實的對象。

2、類圖：

3、結合在裝飾模式的類圖說明它的角色：

　　●　　抽象構件(Component)角色：給出一個抽象接口，以規範準備接收附加責任的對象。

　　●　　具體構件(ConcreteComponent)角色：定義一個将要接收附加責任的類。

　　●　　裝飾(Decorator)角色：持有一個構件(Component)對象的執行個體，并定義一個與抽象構件接口一緻的接口。

　　●　　具體裝飾(ConcreteDecorator)角色：負責給構件對象“貼上”附加的責任。

4、執行個體說明：執行個體1

總結一個從别人部落格上看過的例子來說一下！(網址：http://www.cnblogs.com/java-my-life/archive/2012/04/20/2455726.html)

孫悟空有七十二般變化，他的每一種變化都給他帶來另外一種本領。他變成魚兒時，就可以到水裡遊泳；他變成鳥兒時，就可以在天上飛行。

執行個體中，Component角色便由齊天大聖扮演；ConcreteComponent角色便屬于大聖的本尊、Decorator角色由大聖的七十二變扮演。而ConcreteDecorator角色便是魚兒、鳥兒等七十二般變化之後的結果。

抽象構件角色“齊天大聖”接口定義了一個move()方法，這是所有的具體構件類和裝飾類必須實作的。

//大聖的尊号      

public interface TheGreatestSage {
    	public void move();
    }      

具體構件角色：大聖本尊類

public class Monkey implements TheGreatestSage {
    @Override
    public void move() {
        //代碼
        System.out.println("Monkey Move");
    }
}      

抽象裝飾角色：七十二變

public class Change implements TheGreatestSage {
    private TheGreatestSage sage;
    public Change(TheGreatestSage sage){
        this.sage = sage;
    }
    @Override
    public void move() {
        // 代碼
        sage.move();
    }
}      

具體裝飾角色：魚兒

public class Fish extends Change {
    public Fish(TheGreatestSage sage) {
        super(sage);
    }
    @Override
    public void move() {
        // 代碼
        System.out.println("Fish Move");
    }
}      

具體裝飾角色：鳥兒

public class Bird extends Change {
    public Bird(TheGreatestSage sage) {
        super(sage);
    }
    @Override
    public void move() {
        // 代碼
        System.out.println("Bird Move");
    }
}      

 用戶端類

public class Client {
    public static void main(String[] args) {
        TheGreatestSage sage = new Monkey();
        TheGreatestSage bird = new Bird(sage);
        TheGreatestSage fish = new Fish(bird);
        fish.move(); 
    }

}      

“大聖本尊”是ConcreteComponent類，而“鳥兒”、“魚兒”是裝飾類。要裝飾的是“大聖本尊”。

例子中，系統把大聖從一隻猢狲裝飾成了一隻鳥兒，也就把猢狲的功能替換成了鳥兒的功能，然後又把鳥兒裝飾成了一條魚兒，又把鳥兒的功能替換成了魚兒的功能。

上面的例子便是一個标準的裝飾者模式！

5、透明性的要求

　　裝飾者模式對用戶端的透明性要求程式不要聲明一個ConcreteComponent類型的變量，而應當聲明一個Component類型的變量。

　　用上面例子來說，必須永遠把孫悟空的所有變化都當成孫悟空來對待，而如果把老孫變成的魚兒當成魚兒，而不是老孫，那就被老孫騙了，而這時不應當發生的。

下面的做法是對的：

TheGreatestSage sage = new Monkey();
TheGreatestSage bird = new Bird(sage);      

而下面的做法是不對的：

Monkey sage = new Monkey();
Bird bird = new Bird(sage);      

6、半透明的裝飾模式1

　　但是，現實中純粹的裝飾者模式很難找到。

裝飾者模式的用意是在不改變接口的前提下，增強所考慮的類的功能。在增強功能的時候，卻往往需要建立新的公開的方法。即便是在孫大聖的系統裡，也需要新的方法。比如齊天大聖類并沒有飛行的能力，而鳥兒有。這就意味着鳥兒應當有一個新的fly()方法。再比如，齊天大聖類并沒有遊泳的能力，而魚兒有，這就意味着在魚兒類裡應當有一個新的swim()方法。

　　這就導緻了大多數的裝飾模式的實作都是“半透明”的，而不是完全透明的。換言之，允許裝飾模式改變接口，增加新的方法。這意味着用戶端可以聲明ConcreteDecorator類型的變量，進而可以調用ConcreteDecorator類中才有的方法：

TheGreatestSage sage = new Monkey();
Bird bird = new Bird(sage);
bird.fly();      

　　半透明的裝飾模式是介于裝飾模式和擴充卡模式之間的。擴充卡模式的用意是改變所考慮的類的接口，也可以通過改寫一個或幾個方法，或增加新的方法來增強或改變所考慮的類的功能。大多數的裝飾模式實際上是半透明的裝飾模式，這樣的裝飾模式也稱做半裝飾、半擴充卡模式。

7、半透明的裝飾模式2

　　裝飾模式和擴充卡模式都是“包裝模式(Wrapper Pattern)”，它們都是通過封裝其他對象達到設計的目的的，但是它們的形态有很大差別。

　　理想的裝飾模式在對被裝飾對象進行功能增強的同時，要求具體構件角色、裝飾角色的接口與抽象構件角色的接口完全一緻。而擴充卡模式則不然，一般而言，擴充卡模式并不要求對源對象的功能進行增強，但是會改變源對象的接口，以便和目标接口相符合。

　　裝飾模式有透明和半透明兩種，這兩種的差別就在于裝飾角色的接口與抽象構件角色的接口是否完全一緻。透明的裝飾模式也就是理想的裝飾模式，要求具體構件角色、裝飾角色的接口與抽象構件角色的接口完全一緻。相反，如果裝飾角色的接口與抽象構件角色接口不一緻，也就是說裝飾角色的接口比抽象構件角色的接口寬的話，裝飾角色實際上已經成了一個擴充卡角色，這種裝飾模式也是可以接受的，稱為“半透明”的裝飾模式，如下圖所示。

　　在擴充卡模式裡面，擴充卡類的接口通常會與目标類的接口重疊，但往往并不完全相同。換言之，擴充卡類的接口會比被裝飾的目标類接口寬。

　　顯然，半透明的裝飾模式實際上就是處于擴充卡模式與裝飾模式之間的灰色地帶。如果将裝飾模式與擴充卡模式合并成為一個“包裝模式”的話，那麼半透明的裝飾模式倒可以成為這種合并後的“包裝模式”的代表。

8、執行個體說明：執行個體2.設計模式在JAVA I/O庫中的應用

　　裝飾者模式在Java語言中的最著名的應用莫過于Java I/O标準庫的設計了。

　　由于Java I/O庫需要很多功能的各種組合，如果這些功能都是用繼承的方法實作的，那麼每一種組合都需要一個類，這樣就會造成大量功能重複的類出現。但是，如果采用裝飾者模式，那麼類的數目就會大大減少，功能的重複也可以減至最少。是以裝飾模式是Java I/O庫的基本模式。

　　Java I/O庫的對象結構圖如下，由于Java I/O的對象衆多，是以隻畫出InputStream的部分。

　　根據上圖可以看出：

　　●抽象構件(Component)角色：由InputStream扮演。這是一個抽象類，為各種子類型提供統一的接口。

　　●具體構件(ConcreteComponent)角色：由ByteArrayInputStream、FileInputStream、PipedInputStream、StringBufferInputStream等類扮演。它們實作了抽象構件角色所規定的接口。

　　●抽象裝飾(Decorator)角色：由FilterInputStream扮演。它實作了InputStream所規定的接口。

　　●具體裝飾(ConcreteDecorator)角色：由幾個類扮演，分别是BufferedInputStream、DataInputStream以及兩個不常用到的類LineNumberInputStream、PushbackInputStream。

　　InputStream類型中的裝飾模式是半透明的。為了說明這一點，看一看作裝飾模式的抽象構件角色的InputStream的源代碼。這個抽象類聲明了九個方法，并給出了其中八個的實作，另外一個是抽象方法，需要由子類實作。

public abstract class InputStream implements Closeable {
    public abstract int read() throws IOException;
    public int read(byte b[]) throws IOException {...}
    public int read(byte b[], int off, int len) throws IOException {...}
    public long skip(long n) throws IOException {...}
    public int available() throws IOException {...} 
    public void close() throws IOException {...}
    public synchronized void mark(int readlimit) {...}
    public synchronized void reset() throws IOException {...}
    public boolean markSupported() {...}

}      

　　下面是作為裝飾模式的抽象裝飾角色FilterInputStream類的源代碼。可以看出，FilterInputStream的接口與InputStream的接口是完全一緻的。也就是說，直到這一步，還是與裝飾模式相符合的，屬于完全透明！

public class FilterInputStream extends InputStream {
    protected FilterInputStream(InputStream in) {...}
    public int read() throws IOException {...}
    public int read(byte b[]) throws IOException {...}
    public int read(byte b[], int off, int len) throws IOException {...}
    public long skip(long n) throws IOException {...}
    public int available() throws IOException {...}
    public void close() throws IOException {...}
    public synchronized void mark(int readlimit) {...}
    public synchronized void reset() throws IOException {...}
    public boolean markSupported() {...}
}      

　　下面是具體裝飾角色PushbackInputStream的源代碼。

public class PushbackInputStream extends FilterInputStream {
    public PushbackInputStream(InputStream in, int size) {...}
    public PushbackInputStream(InputStream in) {...}
    public int read() throws IOException {...}
    public int read(byte[] b, int off, int len) throws IOException {...}      

//public int read(byte b[]) throws IOException {...}從類 java.io.FilterInputStream 繼承的方法      

public void unread(int b) throws IOException {...}
    public void unread(byte[] b, int off, int len) throws IOException {...}
    public void unread(byte[] b) throws IOException {...}
    public int available() throws IOException {...}
    public long skip(long n) throws IOException {...}
    public boolean markSupported() {...}
    public synchronized void mark(int readlimit) {...}
    public synchronized void reset() throws IOException {...}
    public synchronized void close() throws IOException {...}
}      

 　　檢視源碼，你會發現，這個裝飾類提供了額外的方法unread()，這就意味着PushbackInputStream是一個半透明的裝飾類。換言 之，它破壞了理想的裝飾模式的要求。如果用戶端持有一個類型為InputStream對象的引用in的話，那麼如果in的真實類型是 PushbackInputStream的話，隻要用戶端不需要使用unread()方法，那麼用戶端一般沒有問題。但是如果用戶端必須使用這個方法，就 必須進行向下類型轉換。将in的類型轉換成為PushbackInputStream之後才可能調用這個方法。但是，這個類型轉換意味着用戶端必須知道它 拿到的引用是指向一個類型為PushbackInputStream的對象。這就破壞了使用裝飾模式的原始用意。

　　現實世界與理論總歸是有一段差距的。純粹的裝飾模式在真實的系統中很難找到。一般所遇到的，都是這種半透明的裝飾模式。

　　下面是使用I/O流讀取檔案内容的簡單操作示例。

public class IOTest {
    public static void main(String[] args) throws IOException {
        // 流式讀取檔案
        DataInputStream dis = null;
        try{
            dis = new DataInputStream(
                    new BufferedInputStream(
                            new FileInputStream("test.txt")
                    )
            );
            //讀取檔案内容
            byte[] bs = new byte[dis.available()];
            dis.read(bs);
            String content = new String(bs);
            System.out.println(content);
        }finally{
            dis.close();
        }
    }

}      

觀察上面的代碼，會發現最裡層是一個FileInputStream對象，然後把它傳遞給一個BufferedInputStream對象，經過BufferedInputStream處理，再把處理後的對象傳遞給了DataInputStream對象進行處理，這個過程其實就是裝飾器的組裝過程，FileInputStream對象相當于原始的被裝飾的對象，而BufferedInputStream對象和DataInputStream對象則相當于裝飾器。

8、總結

一、裝飾者模式的特點：

1)裝飾對象和真實對象有相同的接口。這樣用戶端對象就能以和真實對象相同的方式和裝飾對象互動。 2)裝飾對象包含一個真實對象的引用（reference） 3)裝飾對象接受所有來自用戶端的請求。它把這些請求轉發給真實的對象。 4)裝飾對象可以在轉發這些請求以前或以後增加一些附加功能。這樣就確定了在運作時，不用修改給定對象的結構就可以在外部增加附加的功能。在面向對象的設計中，通常是通過繼承來實作對給定類的功能擴充。 二、裝飾者模式的使用場景： 1)需要擴充一個類的功能，或給一個類添加附加職責。 2)需要動态的給一個對象添加功能，這些功能可以再動态的撤銷。 3)需要增加由一些基本功能的排列組合而産生的非常大量的功能，進而使繼承關系變的不現實。 4)當不能采用生成子類的方法進行擴充時。一種情況是，可能有大量獨立的擴充，為支援每一種組合将産生大量的子類，使得子類數目呈爆炸性增長。另一種情況可能是因為類定義被隐藏，或類定義不能用于生成子類。 三、裝飾者模式的優點：

1)Decorator模式與繼承關系的目的都是要擴充對象的功能，但是Decorator可以提供比繼承更多的靈活性。 裝飾模式允許系統動态決定“貼上”一個需要的“裝飾”，或者除掉一個不需要的“裝飾”。繼承關系則不同，繼承關系是靜态的，它在系統運作前就決定了。 2)通過使用不同的具體裝飾類以及這些裝飾類的排列組合，設計師可以創造出很多不同行為的組合。 四、修飾者模式的缺點：

1)這種比繼承更加靈活機動的特性，也同時意味着更加多的複雜性。 2)裝飾模式會導緻設計中出現許多小類，如果過度使用，會使程式變得很複雜。 3)裝飾模式是針對抽象元件（Component）類型程式設計。但是，如果你要針對具體元件程式設計時，就應該重新思考你的應用架構，以及裝飾者是否合适。當然也可以改變Component接口，增加新的公開的行為，實作“半透明”的裝飾者模式。在實際項目中要做出最佳選擇。 五、裝飾者模式的設計原則：

1)多用組合，少用繼承。 利用繼承設計子類的行為，是在編譯時靜态決定的，而且所有的子類都會繼承到相同的行為。然而，如果能夠利用組合的做法擴充對象的行為，就可以在運作時動态地進行擴充。 2)類應設計的對擴充開放，對修改關閉。

菜鳥一枚，上面有些是摘錄别人的，感覺大神寫的不錯！如果大家有什麼好的例子希望共享一下！