動態地給一個物件新增一些額外的職責。就增加功能來說，裝飾模式想必生成子類更為靈活。
 裝飾模式又名包裝（Wrapper）模式。裝飾模式以對客戶端透明的方式擴充套件物件的功能，是繼承關係的一個替代方案。

裝飾模式中的角色有：
1. 抽象構件角色（Component）：給出一個抽象介面，以規範準備接受附加責任的物件。
2. 具體構件角色（ConcreteComponent）：定義一個將要接收附加責任的類。
3. 裝飾角色（Decorator）：持有一個構件（Component）物件的例項，並定義一個與抽象構件介面一致的介面。
4. 具體裝飾角色（ConcreteDecorator）

舉個簡單例子（類比《Head Fisrt》中的星巴克：吃雜糧煎餅，加個雞蛋，加根火腿，加份辣條）
1 抽象構件角色

public abstract class Pancake
{
    protected String name;
    public String getName()
    {
        return this.name;
    }
    public abstract BigDecimal getPrice();
}

2 具體構件角色

public class CoarsePancake extends Pancake
 

{
    public CoarsePancake(){
        this.name = "雜糧煎餅";
    }

    @Override
    public BigDecimal getPrice()
    {
        return new BigDecimal(5);
    }
}

3 裝飾角色

public abstract class Condiment extends Pancake
{
    public abstract String getName();

    public void sold()
    {
        System.out.println(getName()+"："
 
+getPrice());
    }
}

4 具體裝飾角色

public class Egg extends Condiment
{
    private Pancake pancake;
    public Egg(Pancake pancake)
    {
        this.pancake = pancake;
    }

    @Override
    public String getName()
    {
        return pancake.getName()+",加雞蛋";
    }

    @Override
    public BigDecimal getPrice()
    {
        return pancake.getPrice().add(new BigDecimal(1.5));
    }
}

public class Ham extends Condiment
{
    private Pancake pancake;
    public Ham(Pancake pancake)
    {
        this.pancake = pancake;
    }
    @Override
    public String getName()
    {
        return this.pancake.getName()+",加火腿";
    }

    @Override
    public BigDecimal getPrice()
    {
        return pancake.getPrice().add(new BigDecimal(2));
    }
}

public class Lettuce extends Condiment
{
    private Pancake pancake;
    public Lettuce(Pancake pancake)
    {
        this.pancake = pancake;
    }
    @Override
    public String getName()
    {
        return this.pancake.getName()+",加生菜";
    }

    @Override
    public BigDecimal getPrice()
    {
        return pancake.getPrice().add(new BigDecimal(1));
    }
}

5 測試程式碼

        Pancake pancake = new CoarsePancake();
        Condiment egg = new Egg(pancake);
        Condiment ham = new Ham(egg);
        ham.sold();
        Condiment lettuce = new Lettuce(ham);
        lettuce.sold();

測試結果：

雜糧煎餅,加雞蛋,加火腿：8.5
雜糧煎餅,加雞蛋,加火腿,加生菜：9.5

適用場景

1. 想透明並且動態地給物件增加新的職責的時候
2. 給物件增加的職責，在未來存在增加或減少功能
3. 用繼承擴充套件功能不太現實的情況下，應該考慮用組合的方式

優缺點
優點：

1. 通過組合而非繼承的方式，實現了動態擴充套件物件的功能的能力。
2. 有效避免了使用繼承的方式擴充套件物件功能而帶來的靈活性差，子類無限制擴張的問題。
3. 充分利用了繼承和組合的長處和短處，在靈活性和擴充套件性之間找到完美的平衡點。
4. 裝飾者和被裝飾者之間雖然都是同一型別，但是它們彼此是完全獨立並可以各自獨立任意改變的。
5. 遵守大部分GRAP原則和常用設計原則，高內聚、低偶合。

缺點：

1. 裝飾鏈不能過長，否則會影響效率。
2. 因為所有物件都是繼承於Component,所以如果Component內部結構發生改變，則不可避免地影響所有子類(裝飾者和被裝飾者)，也就是說，通過繼承建立的關係總是脆弱地，如果基類改變，勢必影響物件的內部，而通過組合建立的關係只會影響被裝飾物件的外部特徵。
3. 只在必要的時候使用裝飾者模式，否則會提高程式的複雜性，增加系統維護難度。

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

根據上圖可以看出：
- 抽象構件(Component)角色：由InputStream扮演。這是一個抽象類，為各種子型別提供統一的介面。
- 具體構件(ConcreteComponent)角色：由ByteArrayInputStream、FileInputStream、PipedInputStream、StringBufferInputStream等類扮演。它們實現了抽象構件角色所規定的介面。
- 抽象裝飾(Decorator)角色：由FilterInputStream扮演。它實現了InputStream所規定的介面。
- 具體裝飾(ConcreteDecorator)角色：由幾個類扮演，分別是BufferedInputStream、DataInputStream以及兩個不常用到的類LineNumberInputStream、PushbackInputStream。

歡迎支援筆者新書：《RabbitMQ實戰指南》以及關注微信公眾號：Kafka技術專欄。