例子

星巴茲是以擴張速度最快而聞名的咖啡連鎖店。因為擴張速度實在太快，他們著急更新訂單系統，來匹配他們的飲料供應要求。

實現1---繼承

購買咖啡時，也可以要求其中加入各種調料，例如：蒸奶，豆漿

很明顯，星巴茲為自己製造了一個維護噩夢，如果牛奶的價錢上揚，怎麼辦？新增一種焦糖調料風味時，怎麼辦

調料價格改變會迫使我們更改現有代碼。
新的調料會迫使我們添加新的方法，並改變超類中的cost方法。
可能有新的飲料。對於其中一些飲料 (冰茶?)，調料可能不適合，然而，Tea (茶)子類仍將繼承像hasWhip() (是否加奶詢) 這樣的方法。
顧客想要雙倍摩卡，怎麼辦?

如果不通過繼承，要怎麼達到復用？

通過組合和委托，可以在運行時“繼承”行為
當通過子類化繼承行為時，行為是編譯時靜態設置的。另外所有子類必須繼承相同的行為。
但是，如果可以通過組合擴展對象的行為，就可以在運行時動態地做這件事情。
通過這個技巧，就可以把多個新的責任添加到對象甚至包括超類的設計師沒有想到的責任。不必碰他們的代碼!

關於組合在維護代碼方面的效果，你學到了什麼?

通過動態地組合對象，可以通過編寫新代碼添加新的功能，而無須修改已有代碼。因為沒有改變已有代碼，引進bug或導致意外副作用的機會大幅減少。
代碼應該像夜晚的蓮花一樣 (對改變)關閉，像早晨的蓮花一樣(對擴展)開放。

設計原則五：開放-關閉原則

類應該對擴展開放，但對修改關閉；
目標：允許類容易擴展以容納新的行為，而不用修改已有代碼；
優點：可以彈性應對改變，有足夠彈性接受新的功能來應對改變的需求。
在每個地方應用開放-關閉原則是浪費沒有必要的，要專註於設計中最有可能改變的區域，然後在那裡應用該原則。

裝飾者模式

用裝飾者構造飲料訂單

1.以DarkRoast對象開始，【DarkRoast繼承自Beverage，且有一個用來計算飲料價錢的cost()方法。】
2.顧客想要摩卡 (Mocha)，所以建立一個Mocha對象，並用它將DarkRoast對象包(wrap)起來

Mocha對象是一個裝飾者，它的類型“反映”了它所裝飾的對象 (本例中，就是，指的就是Beverage)。
所以Mocha也有一個cost()方法。通過多態也可以把Mocha所包裹的任何Beverase當成是Beverage

3.顧客也想要奶泡 (Whip)，所以需要建立一個Whip裝飾者，並用它將Mocha對象包起來別忘了，DarkRoast繼承自Beverage，且有一個cost()方法，用來計算飲料價錢。
4.現在，該是為顧客算錢的時候了。通過調用最外圈裝飾者 (Whip) 的cost()就可以辦得到。

關於裝飾者

1.裝飾者和被裝飾對象有相同的超類型。
2.可以用一個或多個裝飾者包裝一個對象。
3.鑒於裝飾者和被裝飾者對象有相同的超類型，在任何需要原始對象(被包裝的)的場合，可以傳遞一個被裝飾的對象代替它。
4.裝飾者可以在所委托被裝飾者的行為之前與/或之後，加上自己的行為，以達到特定的目的。(關鍵點)
5.對象可以在任何時候被裝飾，所以可以在運行時動態地、不限量地用你喜歡的裝飾者來裝飾對象。

裝飾者模式

裝飾者模式：動態地將責任附加到對象上。若要擴展功能，裝飾者提供了比繼承更有彈性的替代方案。

實現2---裝飾者模式

Beverage類

public abstract class Beverage{
     String description="Unknown Beverage";
     public String getDescription(){
         return description;
     }
     public abstract double cost();
}

實現抽象類：（裝飾者）

繼承的意義：

裝飾者和被裝飾者必須是一樣的類型，也就是有共同的超類
這裡利用繼承達到“類型匹配”，而不是利用繼承獲得“行為”
裝飾者需要和被裝飾者(即被包裝的組件)有相同的“介面”，因為裝飾者必須能取代被裝飾者

行為獲得：

當我們將裝飾者與組件組合時，就是在加入新的行為，所得到的新行為，並不是集成自超類，而是由組合對象得到的。
行為來自裝飾者和基礎組件，或與其他裝飾者之間的組合關係

//首先必須讓CondimentDecorator能夠取代Beverage，所以將CondimentDecorator擴展自Beverage
public abstract class CondimentDecorator extends Beverage{
    //每個裝飾者將要包裹的Beverage；【我們使用Beverage超類來引用到Beverage；因此，裝飾者可以包裹任何飲料】
    Beverage beverage;

   //所有的調料裝飾者都必須重新實現getDescription方法
    @Override
    public abstract String getDescription();
}

Beverage實現類子類

從濃縮咖啡(Espresso)開始

//首先，讓Espresso擴展自Beverage類，因為Espresso是一種飲料。
public class Espresso extends Beverage{
    //為了要設置飲料的描述，我們寫了一個構造器，description實例變數繼承自Beverage
    public Espresso(){
        description="Espresso";
    }
    //最後，需要計算Espresso的價錢，現在不需要管調料的價錢，直接把Espresso的價格返回即可
    @Override
    public double cost() {
        return 1.99;
    }
}

裝飾者實現類子類

我們已經完成了抽象組件(Beverage)，有了具體組件(Espresso等),也有了抽象裝飾者(CondimentDecorator)。現在， 我們就來實現具體裝飾者；
先從摩卡(Mocha)下手：

//摩卡是一個裝飾者，所以讓它擴展自CondimentDecorator。別忘了，CondimentDecorator擴展自Beverage
public class Mocha extends CondimentDecorator{
    public Mocha(Beverage beverage){
        this.beverage=beverage;//該類繼承了CondimentDecorator中的Beverage實例變數；來持有正在包裹的飲料
    }

    //返回加入調料後的描述
    @Override
    public String getDescription() {
        return beverage.getDescription()+",Mocha";
    }

    //返回裝飾後的價格
    //首先調用委托給正在裝飾的對象，計算價格；然後把摩卡價格添上去。
    @Override
    public double cost() {
        return 0.20+beverage.cost();
    }
}

Whip（奶泡）

public class Whip extends  CondimentDecorator{

    public Whip(Beverage beverage){
        this.beverage=beverage;
    }

    @Override
    public String getDescription() {
        return beverage.getDescription()+",Whip";
    }

    @Override
    public double cost() {
        return 0.10+beverage.cost();
    }
}

測試

class StarbuzzCoffee{
    public static void main(String arg[]){
        //不加調料的濃縮咖啡
        Beverage beverage1=new Espresso();
        System.out.println(beverage1.getDescription()+"$"+beverage.cost());
        
        //雙倍摩卡咖啡加奶泡
        Beverage beverage2=new DarkRoast();
        beverage2 = new Mocha(beverage2);
        beverage2 = new Whip(beverage2);
        System.out.println(beverage2.getDescription()+"$"+beverage.cost());
    }
}

真實世界的裝飾者：Java I/O

裝飾java.io類

總結

OO原則：

封裝變化
組合優於繼承。
針對介面編程，而不是針對實現編程。
為交互對象之間的松耦合設計而努力。
類應該對擴展開放，對修改關閉。【讓關閉的部分和新擴展的部分隔離。】

裝飾者模式：給對象動態附加額外的責任。對於擴展功能，除了子類化之外,裝飾者提供了彈性的替代做法。

問題：

引入裝飾者會增加實例化組件所需代碼的複雜度。
一旦用了裝飾者，不只要實例化組件，還要把它包裹進裝飾者中，誰知道有幾個裝飾者。

要點

1.繼承是擴展形式之一，但未必是達到彈性設計的最佳方式。在我們的設計中，應該允許行為可以被擴展，而無需修改已有代碼。
2.組合和委托經常可以用來在運行時添加新行為。
3.裝飾者模式提供了子類化擴展行為的替代品。
4.裝飾者模式涉及一群裝飾者類，這些類用來包裝具體組件。
5.裝飾者類反映了它們所裝飾的組件類型(事實上，它們和所裝飾的組件類型相同，都經過了繼承或介面實現)。
6.裝飾者通過在對組件的方法調用之前(或/和之後，甚至在那一刻)添加功能改變其組件的行為。(關鍵點)
7.你可以用任意數目的裝飾者來包裹一個組件。
8.裝飾者一般對組件的客戶是透明的，除非客戶依賴於組件的具體類型。
9.裝飾者會導致設計中出現許多小對象，過度使用會讓代碼變得複雜。