設計原則：
開放-關閉原則，對擴充套件開放，對修改封閉
多用組合，少用繼承
針對介面程式設計，不針對實現程式設計
為互動物件之間的松耦合設計而努力
類圖待補充
示例：飲料銷售系統
主體飲料：coffe
輔助調料：mocha，soy，whip。。
輔助調料價位都不一樣，當輔助調料和主飲料不同搭配時，最終飲料價錢和飲料名稱都不一樣
如客戶要：coffe+mocha，或者coffe+whip等等
假如我們使用簡單繼承方式，定義乙個基類coffe，其他任意飲料組合都繼承自該基類，那麼如果主飲料和輔助飲料有上百種組合
那麼我們就要定義上百個基類，因為每種組合價錢和配料不一樣；而且，當某一中調料價位發生變化時候，可能上百個用到這種調料的類都要修改。
因此，基於oo原則的關-閉原則，選擇裝飾模式，
飲料當作元件（被裝飾者，用輔助調料裝飾飲料成為不同口感售賣飲料）
調料作為裝飾者
（見上面類圖）
show code
1.調料基類
/*** created by supertool on 15-4-21.
* 飲料抽象類
*/public abstract class beverage
// 飲料**
public abstract double
cost();
}
被裝飾者具體類（即每種咖啡）
例如意式濃縮咖啡
public class espresso extends beverage// 不許要管調料價錢，只需把設定
espresso
價錢@override
public double
cost()
}
2.裝飾者
裝飾者抽象類
/*** created by supertool on 15-4-21.
* 調料裝飾
base class
*/public abstract class codimentdecorator extends beverage
裝飾者具體類（即每種調料）
/*** created by supertool on 15-4-21.
*/public class mochadecorator extends codimentdecorator
@override
public string getdescription()
@override
public double
cost()
}
/*** created by supertool on 15-4-21.
*/public class soydecorator extends codimentdecorator
@override
public string getdescription()
@override
public double
cost()
}
/*** created by supertool on 15-4-21.
*/public class whipdecorator extends codimentdecorator
@override
public string getdescription()
@override
public double
cost()
}
3.客戶類
點一杯帶mocha的濃咖啡
/*** created by supertool on 15-4-21.**/
public class coffestoreclient
}
來一杯whio濃咖啡
public class coffestoreclient}
這樣飲料銷售系統做成了
當飲料價位發生變化時候，我們只需要修改某乙個具體類，而不用修改很多類
當有新品種飲料時候，我們只需繼承增加新類即可構造出新飲料。
但是由上述例子可以看出，當有很多飲料時，會出現非常多的類，這回導致類**，導致最終整個飲料選單點菜時候混亂
後續會有工廠模式和生成器模式來解決這些問題。
裝飾者（Decorator）模式
裝飾者模式是允許向乙個新物件新增新的功能，但又不改變其結構。這種模式建立了乙個裝飾類，用來包裝原有的類，並在保持類方法簽名完整性的前提下，提供了額外的功能。就增加功能來說，裝飾器模式相比生成子類更為靈活。例子 如果我們去咖啡店，有一種咖啡，該咖啡可以加糖，牛奶，奶泡等等，如果我們需要加糖和牛奶，常規...
裝飾者模式 Decorator
1 作用 動態的給物件增加執行的業務，不受數量限制。可以代替子類，同時避免子類與父類的高耦合。增加靈活性。2 構成 2.1 裝飾者抽象類 decorator 可以是介面 最終生成乙個指向被裝飾物件基類 component 例項的引用，並定義乙個與被裝飾物件基類 component 介面一致的介面。通...
裝飾者模式 Decorator
裝飾者模式 動態地將責任附加到物件上，若要擴充套件功能，裝飾者提供了比繼承更有彈性的替代方案。動態地給乙個物件新增一些額外的職責,就增加功能來說,裝飾模式比生成子類更為靈活 要點1.繼承屬於擴充套件形式之一，但不見得是達到彈性設計的最佳方式 2.應該允許行為可以被擴充套件，而無須修改現有的 3.組合...