介紹

裝飾者模式(Decorator Pattern)：動態地給一個物件增加一些額外的職責，增加物件功能來說，裝飾模式比生成子類實作更為靈活，裝飾模式是一種物件結構型模式，

在裝飾者模式中，為了讓系統具有更好的靈活性和可擴展性，我們通常會定義一個抽象裝飾類，而將具體的裝飾類作為它的子類

裝飾模式以對客戶透明的方式動態地給一個物件附加上更多的責任，換言之，客戶端并不會覺得物件在裝飾前和裝飾后有什么不同，裝飾模式可以在不使用創造更多子類的情況下，將物件的功能加以擴展，

裝飾模式的類圖如下：

角色

• Component（抽象構件）：給出一個抽象介面，以規范準備接收附加責任的物件，
• ConcreteComponent（具體構件）：定義一個將要接收附加責任的類，
• Decorator（抽象裝飾類）：持有一個構件(Component)物件的實體，并定義一個與抽象構件介面一致的介面，
• ConcreteDecorator（具體裝飾類）：負責給構件物件“貼上”附加的責任，

由于具體構件類和裝飾類都實作了相同的抽象構件介面，因此裝飾模式以對客戶透明的方式動態地給一個物件附加上更多的責任，換言之，客戶端并不會覺得物件在裝飾前和裝飾后有什么不同，裝飾模式可以在不需要創造更多子類的情況下，將物件的功能加以擴展，

裝飾模式的核心在于抽象裝飾類的設計，

示例代碼

抽象構件角色

public interface Component {
    
    public void sampleOperation();
    
}

具體構件角色

public class ConcreteComponent implements Component {

    @Override
    public void sampleOperation() {
        // 寫相關的業務代碼
    }

}

裝飾角色

public class Decorator implements Component{
    private Component component;
    
    public Decorator(Component component){
        this.component = component;
    }

    @Override
    public void sampleOperation() {
        // 委派給構件
        component.sampleOperation();
    }
    
}

具體裝飾角色

public class ConcreteDecoratorA extends Decorator {

    public ConcreteDecoratorA(Component component) {
        super(component);
    }
    
    @Override
    public void sampleOperation() {
　　　　　super.sampleOperation();
        // 寫相關的業務代碼
    }
}

public class ConcreteDecoratorB extends Decorator {

    public ConcreteDecoratorB(Component component) {
        super(component);
    }
    
    @Override
    public void sampleOperation() {
　　　　  super.sampleOperation();
        // 寫相關的業務代碼
    }
}

星巴克咖啡的例子

方案一

加入不同調料的咖啡，例如：蒸奶（Steamed Milk）、豆漿（Soy）、摩卡（Mocha，也就是巧克力風味）或覆寫奶泡，星巴茲會根據所加入的調料收取不同的費用，所以訂單系統必須考慮到這些調料部分，

方案二 ：將調料內置到Drink類中

這種設計雖然滿足了現在的需求，但是我們想一下，如果出現下面情況，我們怎么辦，

①、調料價錢的改變會使我們更改現有代碼，

②、一旦出現新的調料，我們就需要加上新的方法，并改變超類中的cost()方法，

③、以后可能會開發出新飲料，對這些飲料而言（例如：冰茶），某些調料可能并不適合，但是在這個設計方式中，Tea（茶）子類仍將繼承那些不適合的方法，例如：hasWhip()（加奶泡），

④、萬一顧客想要雙倍摩卡咖啡，怎么辦？

很明顯，上面的設計并不能夠從根本上解決我們所碰到的問題，并且這種設計違反了 開放關閉原則（類應該對擴展開放，對修改關閉，），

那我們怎么辦呢？好啦，裝飾者可以非常完美的解決以上的所有問題，讓我們有一個設計非常nice的咖啡館，

方案三:裝飾者模式

這里的Coffee是一個緩沖層，負責將抽取出所有具體咖啡的共同點

代碼演示

飲料抽象類：

public abstract class Drink
{
   protected String decription="";//描述
   public String getDecription() {
      return decription;
   }
   public abstract Integer cost();//回傳飲料的價格
}

緩沖層：抽取出所有咖啡類的共同特征，即計算價錢

//緩沖層----所有種類咖啡的共同點抽取出來
public abstract class Coffee extends Drink
{
    //共同特點：計算價格
    @Override
    public Integer cost() {
        //價格從0累加
        return 0;
    }
}

具體的咖啡類:

public class LongBlack extends Coffee
{
    LongBlack()
    {
        decription="美式咖啡";
    }

    @Override
    public Integer cost() {
        return 15;
    }
}


public class ChinaBlack extends Coffee
{
    ChinaBlack()
    {
        decription="中式咖啡";
    }

    @Override
    public Integer cost() {
        return 10;
    }
}


public class Espresso extends Coffee
{
    //設定描述資訊
    Espresso()
    {
        decription="意大利咖啡";
    }
    @Override
    public Integer cost() {
        //意大利咖啡20元
        return 20;
    }
}

抽象裝飾者

//裝飾者
public abstract class Decorator extends Drink
{
    @Override
    public abstract String getDecription();
}

具體裝飾者—即調料

public class Milk extends Decorator{
    Drink drink;

    Milk(Drink drink)
    {
        this.drink=drink;
    }
    @Override
    public String getDecription()
    {
        return "加了牛奶的"+this.drink.getDecription();
    }

    @Override
    public Integer cost()
    {
        return this.drink.cost()+3;
    }
}


public class Chocolate extends Decorator{
     //用一個實體變數記錄飲料，也就是被裝飾者
    Drink drink;
    Chocolate(Drink drink) {
       this.drink=drink;
    }

    @Override
    public String getDecription() {
        return "加了巧克力的"+drink.getDecription();
    }

    @Override
    public Integer cost() {
        //在原有飲料價格的基礎上加上調料味的價格
        return 5+drink.cost();
    }
}

測驗

public class test
{
    @Test
    public void test()
    {
        //模擬下單
        //首先點一個美式咖啡，不加任何調料
        Drink drink=new LongBlack();
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        //給美式咖啡加一個巧克力
        drink=new Chocolate(drink);
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        //給美式咖啡再加一個牛奶
        drink=new Milk(drink);
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        //再把牛奶和巧克力加一次
        drink=new Chocolate(drink);
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        drink=new Milk(drink);
        System.out.println("購買了"+drink.getDecription()+"  花了"+drink.cost());
        System.out.println("====================================================");
        //簡化寫法
        Drink d=new Chocolate(new Milk(new ChinaBlack()));
        System.out.println("購買了"+d.getDecription()+"  花了"+d.cost());
    }
}

裝飾者模式的簡化

大多數情況下，裝飾模式的實作都要比上面給出的示意性例子要簡單，

如果只有一個ConcreteComponent類，那么可以考慮去掉抽象的Component類（介面），把Decorator作為一個ConcreteComponent子類，如下圖所示：

如果只有一個ConcreteDecorator類，那么就沒有必要建立一個單獨的Decorator類，而可以把Decorator和ConcreteDecorator的責任合并成一個類，甚至在只有兩個ConcreteDecorator類的情況下，都可以這樣做，如下圖所示：

透明性的要求

裝飾模式對客戶端的透明性要求程式不要宣告一個ConcreteComponent型別的變數，而應當宣告一個Component型別的變數，

用頂層抽象父類指向具體子類，以多型的形式實作透明性要求

應該像下面這樣寫:

Drink drink=new LongBlack();
//給美式咖啡加一個巧克力
drink=new Chocolate(drink);

而不是這樣寫

Drink drink=new LongBlack();
//給美式咖啡加一個巧克力
Chocolate drink=new Chocolate(drink);

半透明的裝飾模式

然而，純粹的裝飾模式很難找到，裝飾模式的用意是在不改變介面的前提下，增強所考慮的類的性能，

在增強性能的時候，往往需要建立新的公開的方法，

比如巧克力可以單獨售賣，即售賣巧克力棒，那么這里巧克力類里面需要新增加一個sell方法，用于單獨售賣

這就導致了大多數的裝飾模式的實作都是“半透明”的，而不是完全透明的，換言之，允許裝飾模式改變介面，增加新的方法，這意味著客戶端可以宣告ConcreteDecorator型別的變數，從而可以呼叫ConcreteDecorator類中才有的方法：

Drink drink=new LongBlack();
//給美式咖啡加一個巧克力
Chocolate drink=new Chocolate(drink);
//售賣巧克力棒
drink.sell();

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

裝飾模式的優點

• 對于擴展一個物件的功能，裝飾模式比繼承更加靈活性，不會導致類的個數急劇增加，
• 可以通過一種動態的方式來擴展一個物件的功能，通過組態檔可以在運行時選擇不同的具體裝飾類，從而實作不同的行為，
• 可以對一個物件進行多次裝飾，通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創造出很多不同行為的組合，得到功能更為強大的物件，
• 具體構件類與具體裝飾類可以獨立變化，用戶可以根據需要增加新的具體構件類和具體裝飾類，原有類別庫代碼無須改變，符合 “開閉原則”，

裝飾模式的缺點

• 使用裝飾模式進行系統設計時將產生很多小物件，這些物件的區別在于它們之間相互連接的方式有所不同，而不是它們的類或者屬性值有所不同，大量小物件的產生勢必會占用更多的系統資源，在一定程式上影響程式的性能，
• 裝飾模式提供了一種比繼承更加靈活機動的解決方案，但同時也意味著比繼承更加易于出錯，排錯也很困難，對于多次裝飾的物件，除錯時尋找錯誤可能需要逐級排查，較為繁瑣，

裝飾模式注意事項

(1) 盡量保持裝飾類的介面與被裝飾類的介面相同，這樣，對于客戶端而言，無論是裝飾之前的物件還是裝飾之后的物件都可以一致對待，這也就是說，在可能的情況下，我們應該盡量使用透明裝飾模式，

(2) 盡量保持具體構件類是一個“輕”類，也就是說不要把太多的行為放在具體構件類中，我們可以通過裝飾類對其進行擴展，

(3) 如果只有一個具體構件類，那么抽象裝飾類可以作為該具體構件類的直接子類，

適用場景

• 在不影響其他物件的情況下，以動態、透明的方式給單個物件添加職責，
• 當不能采用繼承的方式對系統進行擴展或者采用繼承不利于系統擴展和維護時可以使用裝飾模式，不能采用繼承的情況主要有兩類：第一類是系統中存在大量獨立的擴展，為支持每一種擴展或者擴展之間的組合將產生大量的子類，使得子類數目呈爆炸性增長；第二類是因為類已定義為不能被繼承（如Java語言中的final類）

設計模式在JAVA I/O庫中的應用

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

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

Java I/O庫的物件結構圖如下，由于Java I/O的物件眾多，因此只畫出InputStream的部分，

下面是使用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物件則相當于裝飾器，

透明和半透明的裝飾模式的區別

理想的裝飾模式在對被裝飾物件進行功能增強的同時，要求具體構件角色、裝飾角色的介面與抽象構件角色的介面完全一致，

而配接器模式則不然，一般而言，配接器模式并不要求對源物件的功能進行增強，但是會改變源物件的介面，以便和目標介面相符合，

裝飾模式有透明和半透明兩種，這兩種的區別就在于裝飾角色的介面與抽象構件角色的介面是否完全一致，

透明的裝飾模式也就是理想的裝飾模式，要求具體構件角色、裝飾角色的介面與抽象構件角色的介面完全一致，

相反，如果裝飾角色的介面與抽象構件角色介面不一致，也就是說裝飾角色的介面比抽象構件角色的介面寬的話，裝飾角色實際上已經成了一個配接器角色，這種裝飾模式也是可以接受的，稱為“半透明”的裝飾模式，如下圖所示

在配接器模式里面，配接器類的介面通常會與目標類的介面重疊，但往往并不完全相同，換言之，配接器類的介面會比被裝飾的目標類介面寬，

顯然，半透明的裝飾模式實際上就是處于配接器模式與裝飾模式之間的灰色地帶，如果將裝飾模式與配接器模式合并成為一個“包裝模式”的話，那么半透明的裝飾模式倒可以成為這種合并后的“包裝模式”的代表，

參考文章

設計模式 | 裝飾者模式及典型應用

齊天大圣的故事

星巴茲咖啡的故事