學過面向物件的我們都知道，通過繼承：能夠重用和擴充套件已經被徹底測試過的程式碼，且無需修改之。但就像策略模式中所講到的，繼承會禁錮類的方法。那麼如果要擴充套件功能，我們還是必須使用繼承嗎？

              答案當然是否定的，因為設計模式中為我們提供了一個很好的模式--裝飾模式：動態地將責任附加到物件上。這裡所謂的動態可以簡單理解為靈活。那麼不使用繼承，又要如何幫助我們達到目的呢？下面一起來看。

             先來看一個例子，我們去咖啡店買咖啡，光咖啡型別就有不同的選擇：綜合、深焙、低咖啡因、濃縮。但喝咖啡可沒這麼簡單，它還需要加入相應的配料來滿足顧客口味需求：牛奶、豆漿、摩卡、奶泡。現在咖啡店要增加一些新口味和型別，那麼原先使用繼承的系統將不再適用，一旦增加的型別和種類增多下面的這張圖就變成一坨了吧：

         那麼使用裝飾模式應該是什麼樣的呢？

            像上面這幅圖顯示的這樣，我們將具體的咖啡型別和配料都作為一個類的子類，通過型別和配料的自由組合實現功能的同時實現程式碼的複用性，提高後期的可維護性。其程式碼如下： 

1.抽象類

<span style="font-size:18px;">package 巴茲咖啡;
//這是一個抽象類。
public abstract class Beverage {
	String description ="Unknown Beverage";
	
	public String getDescription (){
		//獲取咖啡調配方法
		return description;
	}
	
	public abstract double cost();
}
</span>
 

2.具體元件

public abstract class CondimentDecorator extends Beverage {
	public abstract String getDescription();
}

public class DarkRoast extends Beverage {

	public DarkRoast() {
		description ="DarkRoast Coffee";   
	}
	
	public double cost(){
		return .99;
	}

}
</span>

public class Espresso extends Beverage {
	
	public Espresso ()
	{
		description ="Espresso";
	}
	
	public double cost(){
		return 1.99;
	}
}
 

public class HouseBlend extends Beverage {
	public HouseBlend(){
		description ="House Blend Coffee";
	}
	
	public double cost(){
		return .89;
	}
}
</span>

          其他幾個類和上面列舉的類似，大家可以動手實現。最終會實現下面的效果：

            如果店內有需求，要實現杯型大小來進行收費，那麼我們可以在CondimentDecorator中新增中杯、小杯、大杯三個類，抽象類中新增方法：getSize（）對杯型進行獲取，然後通過杯型、咖啡型別和配料的不同搭配來實現靈活收費。這樣一來也就實現了動態的新增的同時也達到了解耦的效用。豈不是一舉兩得？

總結：

 1.裝飾模式中使用組合和委託在系統執行時對系統動態的增加功能。而該模式也就意味著我們要建立一堆的裝飾者類，而它們又恰好是用來裝飾元件的，比如：Mocha、Whip等四個配料都是用來裝飾HouseBlend、 DarkRoast這 些咖啡型別的。

2.我們可以使用一個或者多個裝飾者包裝一個元件：調配出一箇中杯的，加入牛奶、摩卡等的低咖啡因咖啡。

3.裝飾者會導致設計中出現許多小物件，如果過度使用，程式依舊會變得複雜。也就是說，我們不能將咖啡的型別和配料的種類無限的擴張，否則系統會因為過多的咖啡種類和配料而執行緩慢甚至癱瘓。凡事遵循一個度的問題，東西再好吃也不能撐死，模式再好用也不能拖死系統。

所以說，在一定程度上，裝飾者模式還是很棒的呢。

            最後祝大家軟考順利，考試加油，let's  go !!