Java設計模式之java裝飾者模式詳解
介紹
裝飾者模式(Decorator Pattern)：動態地給一個對象增加一些額外的職責，增加對象功能來說，裝飾模式比生成子類實現更為靈活。裝飾模式是一種對象結構型模式。
在裝飾者模式中，為瞭讓系統具有更好的靈活性和可擴展性，我們通常會定義一個抽象裝飾類，而將具體的裝飾類作為它的子類
裝飾模式以對客戶透明的方式動態地給一個對象附加上更多的責任。換言之，客戶端並不會覺得對象在裝飾前和裝飾後有什麼不同。裝飾模式可以在不使用創造更多子類的情況下，將對象的功能加以擴展。
裝飾模式的類圖如下：
角色
- Component（抽象構件）：給出一個抽象接口，以規范準備接收附加責任的對象。
- ConcreteComponent（具體構件）：定義一個將要接收附加責任的類。
- Decorator（抽象裝飾類）：持有一個構件(Component)對象的實例，並定義一個與抽象構件接口一致的接口。
- ConcreteDecorator（具體裝飾類）：負責給構件對象“貼上”附加的責任。
由於具體構件類和裝飾類都實現瞭相同的抽象構件接口，因此裝飾模式以對客戶透明的方式動態地給一個對象附加上更多的責任，換言之，客戶端並不會覺得對象在裝飾前和裝飾後有什麼不同。裝飾模式可以在不需要創造更多子類的情況下，將對象的功能加以擴展。
裝飾模式的核心在於抽象裝飾類的設計。
示例代碼
抽象構件角色
public interface Component {
public void sampleOperation();
}
具體構件角色
public class ConcreteComponent implements Component {
@Override
public void sampleOperation() {
// 寫相關的業務代碼
}
}
裝飾角色
public class Decorator implements Component{
private Component component;
public Decorator(Component component){
this.component = component;
}
@Override
public void sampleOperation() {
// 委派給構件
component.sampleOperation();
}
}
具體裝飾角色
public class ConcreteDecoratorA extends Decorator {
public ConcreteDecoratorA(Component component) {
super(component);
}
@Override
public void sampleOperation() {
super.sampleOperation();
// 寫相關的業務代碼
}
}
public class ConcreteDecoratorB extends Decorator {
public ConcreteDecoratorB(Component component) {
super(component);
}
@Override
public void sampleOperation() {
super.sampleOperation();
// 寫相關的業務代碼
}
}
星巴克咖啡的例子
方案一
加入不同調料的咖啡，例如：蒸奶（Steamed Milk）、豆漿（Soy）、摩卡（Mocha，也就是巧克力風味）或覆蓋奶泡。星巴茲會根據所加入的調料收取不同的費用。所以訂單系統必須考慮到這些調料部分。
方案二 ：將調料內置到Drink類中
這種設計雖然滿足瞭現在的需求，但是我們想一下，如果出現下面情況，我們怎麼辦，
①、調料價錢的改變會使我們更改現有代碼。
②、一旦出現新的調料，我們就需要加上新的方法，並改變超類中的cost()方法。
③、以後可能會開發出新飲料。對這些飲料而言（例如：冰茶），某些調料可能並不適合，但是在這個設計方式中，Tea（茶）子類仍將繼承那些不適合的方法，例如：hasWhip()（加奶泡）。
④、萬一顧客想要雙倍摩卡咖啡，怎麼辦？
很明顯，上面的設計並不能夠從根本上解決我們所碰到的問題。並且這種設計違反瞭 開放關閉原則（類應該對擴展開放，對修改關閉。）。
那我們怎麼辦呢？好啦，裝飾者可以非常完美的解決以上的所有問題，讓我們有一個設計非常nice的咖啡館。
方案三:裝飾者模式
這裡的Coffee是一個緩沖層，負責將抽取出所有具體咖啡的共同點
代碼演示
飲料抽象類：
public abstract class Drink
{
protected String decription="";//描述
public String getDecription() {
return decription;
}
public abstract Integer cost();//返回飲料的價格
}
緩沖層：抽取出所有咖啡類的共同特征，即計算價錢
//緩沖層----所有種類咖啡的共同點抽取出來
public abstract class Coffee extends Drink
{
//共同特點：計算價格
@Override
public Integer cost() {
//價格從0累加
return 0;
}
}
具體的咖啡類:
public class LongBlack extends Coffee
{
LongBlack()
{
decription="美式咖啡";
}
@Override
public Integer cost() {
return 15;
}
}
public class ChinaBlack extends Coffee
{
ChinaBlack()
{
decription="中式咖啡";
}
@Override
public Integer cost() {
return 10;
}
}
public class Espresso extends Coffee
{
//設置描述信息
Espresso()
{
decription="意大利咖啡";
}
@Override
public Integer cost() {
//意大利咖啡20元
return 20;
}
}
抽象裝飾者
//裝飾者
public abstract class Decorator extends Drink
{
@Override
public abstract String getDecription();
}
具體裝飾者—即調料
public class Milk extends Decorator{
Drink drink;
Milk(Drink drink)
{
this.drink=drink;
}
@Override
public String getDecription()
{
return "加瞭牛奶的"+this.drink.getDecription();
}
@Override
public Integer cost()
{
return this.drink.cost()+3;
}
}
public class Chocolate extends Decorator{
//用一個實例變量記錄飲料，也就是被裝飾者
Drink drink;
Chocolate(Drink drink) {
this.drink=drink;
}
@Override
public String getDecription() {
return "加瞭巧克力的"+drink.getDecription();
}
@Override
public Integer cost() {
//在原有飲料價格的基礎上加上調料味的價格
return 5+drink.cost();
}
}
測試
public class test
{
@Test
public void test()
{
//模擬下單
//首先點一個美式咖啡，不加任何調料
Drink drink=new LongBlack();
System.out.println("購買瞭"+drink.getDecription()+" 花瞭"+drink.cost());
//給美式咖啡加一個巧克力
drink=new Chocolate(drink);
System.out.println("購買瞭"+drink.getDecription()+" 花瞭"+drink.cost());
//給美式咖啡再加一個牛奶
drink=new Milk(drink);
System.out.println("購買瞭"+drink.getDecription()+" 花瞭"+drink.cost());
//再把牛奶和巧克力加一次
drink=new Chocolate(drink);
System.out.println("購買瞭"+drink.getDecription()+" 花瞭"+drink.cost());
drink=new Milk(drink);
System.out.println("購買瞭"+drink.getDecription()+" 花瞭"+drink.cost());
System.out.println("====================================================");
//簡化寫法
Drink d=new Chocolate(new Milk(new ChinaBlack()));
System.out.println("購買瞭"+d.getDecription()+" 花瞭"+d.cost());
}
}
裝飾者模式的簡化
大多數情況下，裝飾模式的實現都要比上面給出的示意性例子要簡單。
如果隻有一個ConcreteComponent類，那麼可以考慮去掉抽象的Component類（接口），把Decorator作為一個ConcreteComponent子類。如下圖所示：
如果隻有一個ConcreteDecorator類，那麼就沒有必要建立一個單獨的Decorator類，而可以把Decorator和ConcreteDecorator的責任合並成一個類。甚至在隻有兩個ConcreteDecorator類的情況下，都可以這樣做。如下圖所示：
透明性的要求
裝飾模式對客戶端的透明性要求程序不要聲明一個ConcreteComponent類型的變量，而應當聲明一個Component類型的變量。
用頂層抽象父類指向具體子類，以多態的形式實現透明性要求
應該像下面這樣寫:
Drink drink=new LongBlack(); //給美式咖啡加一個巧克力 drink=new Chocolate(drink);
而不是這樣寫
Drink drink=new LongBlack(); //給美式咖啡加一個巧克力 Chocolate drink=new Chocolate(drink);
半透明的裝飾模式
然而，純粹的裝飾模式很難找到。裝飾模式的用意是在不改變接口的前提下，增強所考慮的類的性能。
在增強性能的時候，往往需要建立新的公開的方法。
比如巧克力可以單獨售賣，即售賣巧克力棒，那麼這裡巧克力類裡面需要新增加一個sell方法，用於單獨售賣
這就導致瞭大多數的裝飾模式的實現都是“半透明”的，而不是完全透明的。換言之，允許裝飾模式改變接口，增加新的方法。這意味著客戶端可以聲明ConcreteDecorator類型的變量，從而可以調用ConcreteDecorator類中才有的方法：
Drink drink=new LongBlack(); //給美式咖啡加一個巧克力 Chocolate drink=new Chocolate(drink); //售賣巧克力棒 drink.sell();
半透明的裝飾模式是介於裝飾模式和適配器模式之間的。適配器模式的用意是改變所考慮的類的接口，也可以通過改寫一個或幾個方法，或增加新的方法來增強或改變所考慮的類的功能。大多數的裝飾模式實際上是半透明的裝飾模式，這樣的裝飾模式也稱做半裝飾、半適配器模式。
裝飾模式的優點
- 對於擴展一個對象的功能，裝飾模式比繼承更加靈活性，不會導致類的個數急劇增加。
- 可以通過一種動態的方式來擴展一個對象的功能，通過配置文件可以在運行時選擇不同的具體裝飾類，從而實現不同的行為。
- 可以對一個對象進行多次裝飾，通過使用不同的具體裝飾類以及這些裝飾類的排列組合，可以創造出很多不同行為的組合，得到功能更為強大的對象。
- 具體構件類與具體裝飾類可以獨立變化，用戶可以根據需要增加新的具體構件類和具體裝飾類，原有類庫代碼無須改變，符合 “開閉原則”。
裝飾模式的缺點
- 使用裝飾模式進行系統設計時將產生很多小對象，這些對象的區別在於它們之間相互連接的方式有所不同，而不是它們的類或者屬性值有所不同，大量小對象的產生勢必會占用更多的系統資源，在一定程序上影響程序的性能。
- 裝飾模式提供瞭一種比繼承更加靈活機動的解決方案，但同時也意味著比繼承更加易於出錯，排錯也很困難，對於多次裝飾的對象，調試時尋找錯誤可能需要逐級排查，較為繁瑣。
裝飾模式註意事項
(1) 盡量保持裝飾類的接口與被裝飾類的接口相同，這樣，對於客戶端而言，無論是裝飾之前的對象還是裝飾之後的對象都可以一致對待。這也就是說，在可能的情況下，我們應該盡量使用透明裝飾模式。
(2) 盡量保持具體構件類是一個“輕”類，也就是說不要把太多的行為放在具體構件類中，我們可以通過裝飾類對其進行擴展。
(3) 如果隻有一個具體構件類，那麼抽象裝飾類可以作為該具體構件類的直接子類。
適用場景
- 在不影響其他對象的情況下，以動態、透明的方式給單個對象添加職責。
- 當不能采用繼承的方式對系統進行擴展或者采用繼承不利於系統擴展和維護時可以使用裝飾模式。不能采用繼承的情況主要有兩類：第一類是系統中存在大量獨立的擴展，為支持每一種擴展或者擴展之間的組合將產生大量的子類，使得子類數目呈爆炸性增長；第二類是因為類已定義為不能被繼承（如Java語言中的final類）
設計模式在JAVA I/O庫中的應用
裝飾模式在Java語言中的最著名的應用莫過於Java I/O標準庫的設計瞭
由於Java I/O庫需要很多性能的各種組合，如果這些性能都是用繼承的方法實現的，那麼每一種組合都需要一個類，這樣就會造成大量性能重復的類出現。而如果采用裝飾模式，那麼類的數目就會大大減少，性能的重復也可以減至最少。因此裝飾模式是Java I/O庫的基本模式。
Java I/O庫的對象結構圖如下，由於Java I/O的對象眾多，因此隻畫出InputStream的部分。
下面是使用I/O流讀取文件內容的簡單操作示例。
public class IOTest {
public static void main(String[] args) throws IOException {
// 流式讀取文件
DataInputStream dis = null;
try{
dis = new DataInputStream(
new BufferedInputStream(
new FileInputStream("test.txt")
)
);
//讀取文件內容
byte[] bs = new byte[dis.available()];
dis.read(bs);
String content = new String(bs);
System.out.println(content);
}finally{
dis.close();
}
}
}
觀察上面的代碼，會發現最裡層是一個FileInputStream對象，然後把它傳遞給一個BufferedInputStream對象，經過BufferedInputStream處理，再把處理後的對象傳遞給瞭DataInputStream對象進行處理，這個過程其實就是裝飾器的組裝過程，FileInputStream對象相當於原始的被裝飾的對象，而BufferedInputStream對象和DataInputStream對象則相當於裝飾器。
透明和半透明的裝飾模式的區別
理想的裝飾模式在對被裝飾對象進行功能增強的同時，要求具體構件角色、裝飾角色的接口與抽象構件角色的接口完全一致。
而適配器模式則不然，一般而言，適配器模式並不要求對源對象的功能進行增強，但是會改變源對象的接口，以便和目標接口相符合。
裝飾模式有透明和半透明兩種，這兩種的區別就在於裝飾角色的接口與抽象構件角色的接口是否完全一致。
透明的裝飾模式也就是理想的裝飾模式，要求具體構件角色、裝飾角色的接口與抽象構件角色的接口完全一致。
相反，如果裝飾角色的接口與抽象構件角色接口不一致，也就是說裝飾角色的接口比抽象構件角色的接口寬的話，裝飾角色實際上已經成瞭一個適配器角色，這種裝飾模式也是可以接受的，稱為“半透明”的裝飾模式，如下圖所示
在適配器模式裡面，適配器類的接口通常會與目標類的接口重疊，但往往並不完全相同。換言之，適配器類的接口會比被裝飾的目標類接口寬。
顯然，半透明的裝飾模式實際上就是處於適配器模式與裝飾模式之間的灰色地帶。如果將裝飾模式與適配器模式合並成為一個“包裝模式”的話，那麼半透明的裝飾模式倒可以成為這種合並後的“包裝模式”的代表。
參考文章
設計模式 | 裝飾者模式及典型應用
《JAVA與模式》之裝飾模式
設計模式之裝飾者模式
總結
本篇文章就到這裡瞭，希望能夠給你帶來幫助，也希望您能夠多多關註WalkonNet的更多內容！