通過繼承實現子類的行為是在編譯時靜態決定的，而且所有子類都會繼承到相同的行為;而組合可以在執行時動態的進行擴充套件，所以應該盡量利用組合的方法擴充套件物件的行為。執行時的擴充套件遠比編譯時期的繼承威力大
1 裝飾者和被裝飾者必須是一樣的型別，即具有共同的超類。
2 當我們將裝飾者與元件組合時，就是在加入新的行為。
3 j**a i/o中使用了大量的裝飾類
4 裝飾者模式符合開放——關閉模式:允許擴充套件，但是不允許修改**。
j**a**
//超類
package com.quding.mode;
public abstract class beverage
public abstract double cost();
} //裝飾者超類
package com.quding.mode;
public abstract class decorator extends beverage
//具體的子類：
j**a**
package com.quding.mode;
public class coffee1 extends beverage
@override
public string getdescription()
}
//子類2
package com.quding.mode;
public class coffee2 extends beverage
@override
public string getdescription()
}
裝飾者子類：
j**a**
package com.quding.mode;
public class milkdecorator extends decorator
@override
public string getdescription()
@override
public double cost()
}
//子類2
package com.quding.mode;
public class sugardecorator extends decorator
@override
public string getdescription()
@override
public double cost()
}
測試**：
j**a**
package com.quding.mode;
public class maintest
}
總結：以上簡單的幾個類體現了裝飾者模式的精髓。以後當使用繼承時要考慮能否使用裝飾者代替，擴充套件**的彈性。
作者「quding0308的部落格」
設計模式 裝飾者模式
public abstract class beverage public abstract double cost public abstract class condimentdecorator extends beverage public class darkroast extends be...
設計模式 裝飾者模式
沒什麼特別的，之前看懂了，這次自己再複述一下。畢竟把別人講懂了才是真的懂了。主要參考了head first 設計模式。例子講述的是在為星巴克咖啡的製作訂單的情況，比如客人點了飲料，那麼系統會自動算出 不知道是我沒有體會到，還是這個例子不太合適，算出 那麼簡單的事還需要用到類？不過不影響我們思考裝飾者...
設計模式 裝飾者模式
好幾天沒出部落格了，在學習android的一些新控制項的時候，用到了乙個模式，叫裝飾者模式，所以在此講講這個模式。模式，包含以下四個角色 1 抽象構件 component 角色 給出乙個抽象介面，以規範準備接收附加責任的物件。2 具體構件 concretecomponent 角色 定義乙個將要接收附...