轉自
http://miaoxiaodong78.blog.163.com/blog/static/18765136200701232434996/
Decorator設計模式是典型的結構型模式（在GOF的那本模式的Bible中將模式分爲：1.創建型模式；2.結構型模式；3.行爲模式三種）。它的主要用意是：動態地爲對象添加一些額外的功能。（記住上面兩種顏色的詞彙，理解裝飾器模式的精髓所在！）下面是GOF的《Element of reusable Object-Oriented Software》中對Decorator用意的概述：
Decorator Pattern――Attaches additionalresponsibilities to an object dynamically . Decorators provide a flexiblealternative to subclassing for extending functionality .
1 何時需要使用裝飾器模式
GOF的那本Bible中關於裝飾器模式列舉的是一個文本組件與邊框的例子（在這裏我就不舉了，主要是因爲我會在書中舉一個相似的，但卻非常有說服力的例子，它對Swing中的某些本來應該使用Decorator卻沒有使用的對象的改進。同時會提出內包裝、外包裝的概念。看到這個例子後大家仔細體會吧！通過例子告訴大家一點：任何設計不是一成不變的、模式的應用是極其靈活的……）。下面我舉一個“三明治”的例子！
很多人都吃過三明治（我除外！“沒吃過豬肉，俺可聽過豬叫”），都會知道三明治必不可少的是兩塊麪包片，然後可以在夾層里加上蔬菜、沙拉、鹹肉等等，外面可以塗上奶油之類的。假如現在你要爲一個三明治小店構造一個程序，其中要設計各種三明治的對象。可能你已經創建了一個簡單的Sandwich對象，現在要產生帶蔬菜的就是繼承原有的Sandwich添加一個蔬菜的成員變量，看起來很“正點”的做法，以後我還要帶鹹肉的、帶奶油的、帶蔬菜的又分爲帶青菜的、帶芹菜的、生菜的……還是一個一個繼承是吧！假如我們還需要即帶蔬菜又帶其它肉類，設置我們還要求這些添加成分的任意組合，那你就慢慢繼承吧！
讀過幾年書的會下面這個算術，我們有n種成分，在做三明治的時候任意搭配，那麼有多少種方案呢？！算算吧！你會有驚人的發現。N種成分，什麼都不要是Cn0種方案吧！要1種是Cn1吧！…..要n種是Cnn吧！加起來不就是嗎？Cn0+Cn1+……+Cnn-1+Cnn還不會啊！牛頓萊布尼茲公式記得吧！（可惜Word的公式編輯器安裝不了）總共2的n次方案。有可能前面10天寫了K個類，老闆讓你再加一種成分你就得再幹10天，下一次再加一種你可得幹20天哦！同時你可以發現你的類庫急劇地膨脹！（老闆可能會說你：XXX前K天你加了n個成分，怎麼現在這麼不上進呢？後K天只加了1個成分啊？！！可能你會拿個比給老闆算算，老闆那麼忙會睬你嗎？！有可能你的老闆會說：不管怎麼樣我就要你加，K天你還給我加n個成分！！呵呵，怎麼辦啊！跳槽啊!跳槽了也沒人要你！！人家一看就知道你沒學設計模式）。下面我們就使用裝飾器模式來設計這個庫吧！下圖是我們的設計圖：
下面是以上各個類的意義：
1. Ingredient（成分）：所有類的父類，包括它們共有的方法，一般爲抽象類且方法都有默認的實現，也可以爲接口。它有Bread和Decorator兩個子類。這種實際不存在的，系統需要的抽象類僅僅表示一個概念，圖中用紅色表示。
2. Bread（麪包）：就是我們三明治中必須的兩片面包。它是系統中最基本的元素，也是被裝飾的元素，和IO中的媒質流（原始流）一個意義。在裝飾器模式中屬於一類角色，所以其顏色爲紫色。
3. Decorator（裝飾器）：所有其它成分的父類，這些成分可以是豬肉、羊肉、青菜、芹菜。這也是一個實際不存在的類，僅僅表示一個概念，即具有裝飾功能的所有對象的父類。圖中用藍色表示。
4. Pork（豬肉）：具體的一個成分，不過它作爲裝飾成分和麪包搭配。
5. Mutton（羊肉）：同上。
6. Celery（芹菜）：同上。
7. Greengrocery（青菜）：同上。
總結一下裝飾器模式中的四種角色：1.被裝飾對象（Bread）；2.裝飾對象（四種）；3.裝飾器（Decorator）；4.公共接口或抽象類（Ingredient）。其中1和2是系統或者實際存在的，3和4是實現裝飾功能需要的抽象類。
寫段代碼體會其威力吧！（程序很簡單，但是實現的方法中可以假如如何你需要的方法，意境慢慢體會吧！）
所有成分的父類，抽象類有一個描述自己的方法和一個得到價格的方法，以及一個打印自身描述和價格的方法（該方法與上面兩個方法構成模板方法哦！）
public abstract class Ingredient {
public abstract String getDescription();
public abstract double getCost();
public void printDescription(){
System.out.println(" Name "+ this.getDescription());
System.out.println(" Price RMB "+ this.getCost());
}
}//Bread.java
public class Bread extends Ingredient {
private String description ;
public Bread(String desc){
this.description=desc ;
}
public String getDescription(){
return description ;
}
public double getCost(){
return 2.48 ;
}
}裝飾器對象，所有具體裝飾器對象父類。它最經典的特徵就是：1.必須有一個它自己的父類爲自己的成員變量；2.必須繼承公共父類。這是因爲裝飾器也是一種成分，只不過是那些具體具有裝飾功能的成分的公共抽象罷了。在我們的例子中就是有一個Ingredient作爲其成員變量。Decorator繼承了Ingredient類。
public abstract class Decorator extends Ingredient {
Ingredient ingredient ;
public Decorator(Ingredient igd){
this.ingredient = igd;
}
public abstract String getDescription();
public abstract double getCost();
}具體的豬肉成分，同時也是一個具體的裝飾器，因此它繼承了Decorator類。豬肉裝飾器裝飾可以所有的其他對象，因此通過構造器傳入一個Ingredient的實例，程序中調用了父類的構造方法，主要父類實現了這樣的邏輯關係。同樣因爲方法是具體的成分，所以getDescription得到了實現，不過由於它是具有裝飾功能的成分，因此它的描述包含了被裝飾成分的描述和自身的描述。價格也是一樣的。價格放回的格式被裝飾成分與豬肉成分的種價格哦！
//Pork.java
public class Pork extends Decorator{
public Pork(Ingredient igd){
super(igd);
}
public String getDescription(){
String base = ingredient.getDescription();
return base +"\n"+"Decrocated with Pork !";
}
public double getCost(){
double basePrice = ingredient.getCost();
double porkPrice = 1.8;
return basePrice + porkPrice ;
}
}從上面兩個方法中我們可以看出，豬肉裝飾器的功能得到了增強，它不僅僅有自己的描述和價格，還包含被裝飾成分的描述和價格。主要是因爲被裝飾成分是它的成員變量，因此可以任意調用它們的方法，同時可以增加自己的額外的共同，這樣就增強了原來成分的功能。
//Mutton.java
public class Mutton extends Decorator{
public Mutton(Ingredient igd){
super(igd);
}
public String getDescription(){
String base = ingredient.getDescription();
return base +"\n"+"Decrocated with Mutton !";
}
public double getCost(){
double basePrice = ingredient.getCost();
double muttonPrice = 2.3;
return basePrice + muttonPrice ;
}
}//Celery.java
public class Celery extends Decorator{
public Celery(Ingredient igd){
super(igd);
}
public String getDescription(){
String base = ingredient.getDescription();
return base +"\n"+"Decrocated with Celery !";
}
public double getCost(){
double basePrice = ingredient.getCost();
double celeryPrice =0.6;
return basePrice + celeryPrice ;
}
}/GreenGrocery.java
public class GreenGrocery extends Decorator{
public GreenGrocery (Ingredient igd){
super(igd);
}
public String getDescription(){
String base = ingredient.getDescription();
return base +"\n"+"Decrocated with GreenGrocery !";
}
public double getCost(){
double basePrice = ingredient.getCost();
double greenGroceryPrice = 0.4;
return basePrice + greenGroceryPrice ;
}
}下面我們就領略裝飾器模式的神奇了！我們有一個測試類，其中建立夾羊肉的三明治、全蔬菜的三明治、全葷的三明治。（感覺感覺吧！很香的哦！）
public class DecoratorTest{
public static void main(String[] args){
Ingredient compound = new Mutton(new Celery(new Bread("Master24's Bread")));
compound.printDescription();
compound = new Celery(new GreenGrocery(new Bread("Bread with milk")));
compound.printDescription();
compound = new Mutton(new Pork(new Bread("Bread with cheese")));
compound.printDescription();
}
}2 裝飾器模式的結構
在談及軟件中的結構，一般會用UML圖表示（UML和ANT、JUnit等都是軟件設計中基本的工具，會了沒有啊！）。下面是一個我們經常看到的關於Decorator模式的結構圖
1. Component就是裝飾器模式中公共方法的類，在裝飾器模式結構圖的頂層。
2. ConcreateComponent是轉換器模式中具體的被裝飾的類，IO包中的媒體流就是此種對象。
3. Decorator裝飾器模式中的核心對象，所有具體裝飾器對象的父類，完成裝飾器的部分職能。在上面的例子中Decorator類和這裏的對應。該類可以只做一些簡單的包裹被裝飾的對象，也可以還包含對Component中方法的實現……他有一個鮮明的特點：繼承至Component，同時包含一個Component作爲其成員變量。裝飾器模式動機中的動態地增加功能是在這裏實現的。
4. ConcreteDecoratorA和ConcreteDecoratorB是兩個具體的裝飾器對象，他們完成具體的裝飾功能。裝飾功能的實現是通過調用被裝飾對象對應的方法，加上裝飾對象自身的方法。這是裝飾器模式動機中的添加額外功能的關鍵。
從上面圖中你可能還會發現：ConcreteDecoratorA和ConcreteDecoratorB的方法不一樣，這就是一般設計模式中談及裝飾器模式的“透明裝飾器”和“不透明裝飾器”。“透明裝飾器”就是整個Decorator的結構中所有的類都保持同樣的“接口”（這裏是共同方法的意思），這是一種極其理想的狀況，就像餐飲的例子一樣。現實中絕大多數裝飾器都是“不透明裝飾器”，他們的“接口”在某些子類中得到增強，主要看這個類與頂層的抽象類或者接口是否有同樣的公共方法。IO中的ByteArrayInputStream就比Inputstrem抽象類多一些方法，因此IO中的裝飾器是一個“不通明裝飾器”。下面是IO中輸入字節流部分的裝飾器的結構圖。
1. InputStream是裝飾器的頂層類，一個抽象類！包括一些共有的方法，如：1.讀方法――read（3個）；2.關閉流的方法――close；3.mark相關的方法――mark、reset和markSupport；4.跳躍方法――skip；5.查詢是否還有元素方法――available。圖中紅色的表示。
2. FileInputStream、PipedInputStream…五個紫色的，是具體的被裝飾對象。從他們的“接口”中可以看出他們一般都有額外的方法。
3. FilterInputStream是裝飾器中的核心，Decorator對象，圖中藍色的部分。
4. DataInputStream、BufferedInputStream…四個是具體的裝飾器，他們保持了和InputStream同樣的接口。
5. ObjectInputStream是IO字節輸入流中特殊的裝飾器，他不是FilterInputStream的子類（不知道Sun處於何種意圖不作爲FileterInputStream的子類，其中流中也有不少的例子）。他和其他FilterInputStream的子類功能相似都可以裝飾其他對象。
IO包中不僅輸入字節流是採用裝飾器模式、輸出字節流、輸入字符流和輸出字符流都是採用裝飾器模式。
