裝飾者模式（Decorator Pattern)

????*利用組合（composition）和委托（delegation）可以在運行時實現繼承行為的效果，動態地給對象加上新的行為。

????*利用繼承擴展子類的行為，是在編譯時靜態決定的；利用組合的做法，可以在運行時動態地擴展對象的行為。

軟件設計原則：類應該對擴展開放，對修改關閉。這就是我們常說的開放關閉原則。

????*開放-關閉原則使類容易擴展，在不修改代碼的情況下，通過搭配實現新的行為。這樣的設計可以應對改變，比如增加新功能或需求發生變更。

OO設計技巧：允許系統在不修改代碼的情況下，進行功能擴展。
????裝飾者模式：動態地將責任加到對象身上。如果要擴展功能，裝飾者模式提供了比繼承更有彈性的替代方案。
????裝飾者模式中，裝飾者可以在被裝飾者的行為之前或之后，加上自己的行為，以實現特性的目的。

裝飾者模式的幾個缺點：

（1）有時在設計中加入大量的小類，變得不容易理解。
（2）有的客戶端代碼依賴于特定的類型（這是個比較糟糕的習慣，違反了“針對接口編程，而不是針對實現編程”的設計原則），當服務器端引入裝飾者模式時，客戶端就會出現狀況。
（3）裝飾者模式使得實例化組件的復雜度提升。
*遵循開放-關閉原則設計系統，努力使關閉的部分（不變）和開放的部分（變化）隔離開來。

問題背景：

設計一個咖啡訂單系統。咖啡可以加配料，不同的配料收費不同。如果一個顧客想要摩卡（Mocha）和奶泡（Whip）深焙咖啡（DarkRoast）該怎樣去計算費用呢？

類結構圖

Beverage（飲料）是一個抽象類，店內所提供的飲料都必須繼承此類。cost()方法是抽象的，子類必須定義自己的實現。description（敘述）的實例變量，由每個子類設置，用來描述飲料，如“超優深焙咖啡豆”。利用getDescription()方法返回此敘述。購買咖啡時，可以要求在其中加入各種調料，如：牛奶、豆漿、摩卡等。咖啡館會根據所加入的調料收取不同的費用。如果直接用繼承，會造成類爆炸。如果從基類Beverage下手，加上實例變量代表是否加上調料（牛奶、豆漿、摩卡……），看起來是不錯，但是不符合我們的設計原則。如調料價錢改變會使我們更改基類代碼、一旦出現新的調料，我們就需要加上新方法，并改變超類中的cost()等，所以我們使用到了裝飾者模式。

先從Beverage類下手

1 2 3 4 5 6 7 8 9

public abstract class Beverage{ ????publicstring description="Uknown Beverage"； ????//敘述方法已經實理 ????public String getDescription（）{ ????????return description； ????} ????//價線必須在子類中實理 ????public abstract double cost（）； }

實現調料（Condiment）類，同時這個類也是個裝飾者類

//必須讓CondimentDecorator 能夠取代Beverage public abstract class CondimentDecorator extends Beverage{ //所有轉飾者必須重新實現getDescription public abstract String getDescription（）； }基類已經創建好了，讓我們來實現那些飲料（Beverage）類

//讓Espresso擴展自Beverage，因為Espresso是一種飲料

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public class Espresso?extends Beverage { ????//設置飲料的描述 ????public Espresso() { ????????description =?"Espresso"; ????} ????//計算Espresso的價錢，現在不需要管調料的價錢 ????public double cost() { ????return 1.99; ????} } public class HouseBlend?extends Beverage { ????public HouseBlend() { ????????description =?"HouseBlend"; ????} ????public double cost() { ????????return .89; ????} }

我們已經完成了抽象組件（Beverage），有了具體組件（HouseBlend），也有了抽象裝飾者（CondimentDecorator）。現在，我們就來實現具體裝飾者：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

//Mocha是一個裝飾者，所以擴展自CondimentDecorator public class Mocha?extends CondimentDecorator { ????//用一個實例變量記錄飲料，也就是被裝飾者 ????Beverage beverage; ????//把飲料當做構造器參數，再由構造器將此飲料記錄在實例變量中 ????public Mocha(Beverage beverage) { ????????this.beverage = beverage; ????} ????//利用委托的做法，得到一個敘述，然后在其后加上調料的敘述 ????public String getDescription() { ????????return beverage.getDescription() +?"，Mocha"; ????} ????//首先把調用委托給被裝飾者對象，然后再加上Mocha的價錢 ????public double cost() { ????????return .20 + beverage.cost(); ????} }

測試代碼：

1 2 3 4 5 6 7 8 9 10 11

public class App { ????public static void main(String[] args) { ????????//訂一杯Espresso，不需要調料 ????????Beverage espresso =?new Espresso(); ????????System.out.println(espresso.getDescription() +?" $" + espresso.cost()); ????????//訂一杯調料為摩卡的HouseBlend咖啡 ????????Beverage houseBlend =?new HouseBlend(); ????????houseBlend =?new Mocha(houseBlend); ????????System.out.println(houseBlend.getDescription() +?" $" + houseBlend.cost()); ????} }

輸出為：

Espresso?$1.99

HouseBlend，Mocha?$1.09

總結

裝飾者模式:動態地將責任附件到對象上。若要擴展功能，裝飾者提東了比繼承更有彈性的替代方案。

*裝飾者和被裝飾對象有相同的超類型

*你可以用一個或者多個裝飾者包裝一個對象。

*既然裝飾者和被裝飾對象有相同的超類型，所以在任何需要原始對象(被包裝的)的場合，可以用裝飾過的對象代替它。

*裝飾者可以在所委托被裝飾者的行為前與/或之后，加上自己的行為，已達到特定的目的。

*對象可以在任何時候被裝飾，所以可以在運行時動態地、不限量地用你喜歡的裝飾者來裝飾對象

?

設計原則：類應該對擴展開放，對修改關閉(開放-關閉原則)。

注意：遵循開放-關閉原則，通常會引入新的抽象層次，增加代碼的復雜度。你需要把注意力集中在設計中最有可能改變的地方，然后應用開放-關閉原則。在選擇需要被擴展的代碼部分時要小心，每個地方都采用開放-關閉原則，是一種浪費，也沒必要，還會導致代碼變得復雜且難以理解。

要點：

• • 繼承屬于擴展形式之一，但不見得是達到彈性設計的最佳方式。
  • 在我們的設計中，應該允許行為可以被擴展，而無須修改現有的代碼。
  • 組合和委托可用于在運行時動態地加上新的行為。
  • 除了繼承，裝飾者模式也可以讓我們擴展行為，
  • 裝飾者模式意味著一群裝飾者類，這些類用了包裝具體組件。
  • 裝飾者類反映出被裝飾的組件類型(事實上，他們具有相同的類型，都經過接口或繼承實現)。
  • 裝飾者可以在被裝飾者的行為前面與/或后面加上自己的行為，甚至將被裝飾者的行為整個取代掉，而達到特定的目的。
  • 你可以用無數個裝飾者包裝一個組件。
  • 裝飾者一般對組件的客戶是透明的，除非客戶程序依賴于組件的具體類型。
  • 裝飾者會導致設計中出現許多小對象，如果過度使用，會讓程序變得很復雜。

總結

以上是生活随笔為你收集整理的《Head First设计模式》第三章笔记 装饰者模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。