設計模式裝飾者模式

設計模式有乙個重要的原則：類對擴充套件開放，對修改關閉。裝飾者模式對喜歡繼承的人來說是乙個新的設計眼界，但卻是再熟悉不過了。有這樣乙個例子：

沖泡咖啡：

1、拿乙個深焙咖啡來沖泡。

2、感覺咖啡太苦了，放點摩卡修飾它，味道好多了。

3、可是我還想加些奶泡裝飾它，這樣就更好看了。

4、最後在付款的時候**也會增加。

上面的例子展示的是我們對咖啡進行擴充套件的過程。目的是為了說明我們要允許類容易擴充套件，在不修改現有**的情況下，就可以搭配新的行為。這樣的設計具有彈性可以應對改變，可以接受新的功能來應對改變的需求。但是如何設計才能實現可以擴充套件，有又禁止修改呢？

定義裝飾者模式：動態地將責任附加到物件上。若要擴充套件功能，裝飾者提供了比繼承更有彈性的替代方案。

下面我們看乙個**例子。

對咖啡做擴充套件後就該稱為飲料（beverage）了

//定義成抽象類
public abstract class beverage
//在子類中做具體實現
public abstract double cost();
}

beverage很簡單。我們再來實現調料（condiment）抽象類，也就是裝飾者類：

public abstract class condimentdecorator extents beverage

已經有了飲料基礎類，讓我們先實現乙個加糖飲料（sugarcaffee）。

public class addsugarcaffee extends beverage
public double cost()
}

再定義另一種飲料--奶泡（addmilkcaffee）

public class addmilkcaffee extends beverage
public double cost()
}

如果你回頭去看看裝飾者模式的類圖，將發現我們已經完成了抽象元件（beverage），有了具體元件（addsagarcaffee和

addmilkcaffee

），也有了抽象裝飾者（

condimentdecorator

）。現在，我們就來實現具體裝飾者.

mocha是乙個裝飾者，所以擴充套件自condimentdecorator，別忘了condimentdecorator也擴充套件自beverage。

public class mocha extends condimentdecorator
public string getdescription()
public double cost()
}

同樣在定義乙個大豆soy裝飾者。也擴充套件自

condimentdecorator。

public class soy extends condimentdecorator
public string getdescription()
public double cost()
}

現在各種調料都有了，我們例項化乙個物件，然後用調料來裝飾它。

public  class starbuzzcaffee
}

裝飾者該做的事，就是增加行為到包裝物件上。在平時開發中遇到的i/o流（fileinputstream，bufferedinputstream,linenumberinputstream,bufferinputstreamreader等），就是經典的裝飾者模式。

繼承屬於擴充套件形式之一，但不見得是達到彈性設計的最佳方式。在我們的設計中，應該允許行為可以被擴充套件，而無須修改現有的**。裝飾者模式可以在被裝飾者的行為前面與後面加上自己的行為，甚至將被裝飾者的行為整個取代，而達到特定的目的。你可以用無數個裝飾者包裝乙個元件，但是，這也會導致設計中出現許多小物件，如果過度使用，反而讓程式變得很複雜。

總之：裝飾者模式提倡，類，應該對擴充套件開放，對修改關閉。

上圖：最直觀！

設計模式 裝飾者模式

設計模式 裝飾者模式

設計模式 裝飾者模式

設計模式 裝飾者模式

相關推薦

設計模式裝飾者模式

設計模式裝飾者模式

設計模式裝飾者模式

設計模式裝飾者模式