裝飾模式也算一種比較常見的設計模式,工作過程中很少刻意的去實現這種模式，因為這種模式也會帶來一些問題。
比如小類太多,組織起來比較麻煩,對客戶端完全可見,如果不了解各個類的功能會很亂等等
當然也有很多優點: 可以動態的給類增加一些職責,增加功能更加靈活，比起繼承來說也更加具有彈性
下面我們來看看它究竟是什麼樣子的
以買車業務模型為例(本人未買過車,業務場景純屬臆想)
車裡面還有很多裝備可以選擇,根據不同的選擇裝飾決定最後到手的**:
商品**
裸車100000
加熱座椅(可選)
4000
真皮內飾(可選)
8000
蹦迪音響(可選)
5000
package car;
public class car
/*** 新增真皮座椅
*/public void addheatedseat
() /**
* 新增真皮內飾
*/public void adddermalinteriors
() /**
* 新增蹦迪音響
*/public void addbengdisound
() /**
* 獲取總價
** @return
*/public int cost
() }
複製**
package car;
public class main
}複製**
花費**105000
複製**
首先這是我們的場景足夠的簡單,所涉及的配套元件也比較少,實際中可能針對某個方法可能有很複雜的獲取和計算邏輯,元件也會有很多種選擇,會造成類**,無法繼續維護下去
如果我們使用裝飾模式,會帶來什麼改變呢，會給我們帶來什麼樣的體驗呢
宣告抽象類(被裝飾者和裝飾者繼承此類,目的對實現方法進行規正)
package car;
public abstract class car
複製**
package car;
/** * 被裝飾的類 -> 裸車
*/public class nakecar extends car
/*** 獲取總價
** @return
*/public string cost
() }
複製**
加熱座椅
package car;
/** * 裝飾元件
*/public class heatedseat extends car
/*** 獲取**
** @return
*/public string cost
() }
複製**
package car;
public class dermalinteriors extends car
/*** 獲取**
** @return
*/public string cost
() }
複製**
package car;
public class bengdisound extends car
/*** 獲取**
** @return
*/public string cost
() }
複製**
package car;
public class main
}複製**
總花費**:裸車:100000||加熱座椅:4000||蹦迪音響:5000
複製**
設計模式（三） 裝飾者模式
裝飾者結構圖 1 component 被裝飾者的抽象類或介面，定義了新增職責的方法 2 concretecomponent 被裝飾者的具體實現類，如果只有乙個被裝飾者，concretecomponent和component可以合二為一 3 decorator 裝飾者父類，繼承component被裝飾...
設計模式（三）裝飾者模式
星巴克咖啡館想要乙份選單系統，要求能夠計算不同種類咖啡加上不同調料 牛奶 豆漿 摩卡 奶泡。的 tom做了如下實現 每個咖啡都要繼承這個飲料類，然後對是否有各種調料進行配置，然後實現cost 方法。這樣基本解決了這個問題，但是如果現在又增加了幾種飲料，是不是需要更改現在的 呢？如何才能不對以前 做修...
設計模式筆記（三） 裝飾者模式
裝飾者模式 decorator pattern 動態地將責任附加到物件上。若要擴充套件功能，裝飾者提供了比繼承更有彈性的替代方案。簡單點說，裝飾者可以裝飾 也就是在原來功能的基礎上再擴充套件其功能 被裝飾者。乙個被裝飾者可以被多個裝飾者裝飾，或者被相同的裝飾者裝飾多次，是不是很靈活啊。而這就要求裝飾...