例子
星巴茲是以擴張速度最快而聞名的咖啡連鎖店，因為擴張速度實在太快，他們著急更新訂單系統，來匹配他們的飲料供應要求，
實作1---繼承
購買咖啡時，也可以要求其中加入各種調料，例如：蒸奶，豆漿
很明顯，星巴茲為自己制造了一個維護噩夢，如果牛奶的價錢上揚，怎么辦？新增一種焦糖調料風味時，怎么辦
調料價格改變會迫使我們更改現有代碼，
新的調料會迫使我們添加新的方法，并改變超類中的cost方法，
可能有新的飲料，對于其中一些飲料 (冰茶?)，調料可能不適合，然而，Tea (茶)子類仍將繼承像hasWhip() (是否加奶詢) 這樣的方法，
顧客想要雙倍摩卡，怎么辦?
如果不通過繼承，要怎么達到復用？
通過組合和委托，可以在運行時“繼承”行為
當通過子類化繼承行為時，行為是編譯時靜態設定的，另外所有子類必須繼承相同的行為，
但是，如果可以通過組合擴展物件的行為，就可以在運行時動態地做這件事情，
通過這個技巧，就可以把多個新的責任添加到物件甚至包括超類的設計師沒有想到的責任，不必碰他們的代碼!
關于組合在維護代碼方面的效果，你學到了什么?
通過動態地組合物件，可以通過撰寫新代碼添加新的功能，而無須修改已有代碼，因為沒有改變已有代碼，引進bug或導致意外副作用的機會大幅減少，
代碼應該像夜晚的蓮花一樣 (對改變)關閉，像早晨的蓮花一樣(對擴展)開放，
設計原則五：開放-關閉原則
類應該對擴展開放，但對修改關閉；
目標：允許類容易擴展以容納新的行為，而不用修改已有代碼；
優點：可以彈性應對改變，有足夠彈性接受新的功能來應對改變的需求，
在每個地方應用開放-關閉原則是浪費沒有必要的，要專注于設計中最有可能改變的區域，然后在那里應用該原則，
裝飾者模式
用裝飾者構造飲料訂單
1.以DarkRoast物件開始，【DarkRoast繼承自Beverage，且有一個用來計算飲料價錢的cost()方法，】
2.顧客想要摩卡 (Mocha)，所以建立一個Mocha物件，并用它將DarkRoast物件包(wrap)起來
Mocha物件是一個裝飾者，它的型別“反映”了它所裝飾的物件 (本例中，就是，指的就是Beverage)，
所以Mocha也有一個cost()方法，通過多型也可以把Mocha所包裹的任何Beverase當成是Beverage
3.顧客也想要奶泡 (Whip)，所以需要建立一個Whip裝飾者，并用它將Mocha物件包起來別忘了，DarkRoast繼承自Beverage，且有一個cost()方法，用來計算飲料價錢，
4.現在，該是為顧客算錢的時候了，通過呼叫最外圈裝飾者 (Whip) 的cost()就可以辦得到，
關于裝飾者
1.裝飾者和被裝飾物件有相同的超型別，
2.可以用一個或多個裝飾者包裝一個物件，
3.鑒于裝飾者和被裝飾者物件有相同的超型別，在任何需要原始物件(被包裝的)的場合，可以傳遞一個被裝飾的物件代替它，
4.裝飾者可以在所委托被裝飾者的行為之前與/或之后，加上自己的行為，以達到特定的目的，(關鍵點)
5.物件可以在任何時候被裝飾，所以可以在運行時動態地、不限量地用你喜歡的裝飾者來裝飾物件，
裝飾者模式
裝飾者模式：動態地將責任附加到物件上，若要擴展功能，裝飾者提供了比繼承更有彈性的替代方案，
實作2---裝飾者模式
Beverage類
public abstract class Beverage{
String description="Unknown Beverage";
public String getDescription(){
return description;
}
public abstract double cost();
}
實作抽象類：（裝飾者）
繼承的意義：
裝飾者和被裝飾者必須是一樣的型別，也就是有共同的超類
這里利用繼承達到“型別匹配”，而不是利用繼承獲得“行為”
裝飾者需要和被裝飾者(即被包裝的組件)有相同的“介面”，因為裝飾者必須能取代被裝飾者
行為獲得：
當我們將裝飾者與組件組合時，就是在加入新的行為，所得到的新行為，并不是集成自超類，而是由組合物件得到的，
行為來自裝飾者和基礎組件，或與其他裝飾者之間的組合關系
//首先必須讓CondimentDecorator能夠取代Beverage，所以將CondimentDecorator擴展自Beverage
public abstract class CondimentDecorator extends Beverage{
//每個裝飾者將要包裹的Beverage；【我們使用Beverage超類來參考到Beverage；因此，裝飾者可以包裹任何飲料】
Beverage beverage;
//所有的調料裝飾者都必須重新實作getDescription方法
@Override
public abstract String getDescription();
}
Beverage實作類子類
從濃縮咖啡(Espresso)開始
//首先，讓Espresso擴展自Beverage類，因為Espresso是一種飲料，
public class Espresso extends Beverage{
//為了要設定飲料的描述，我們寫了一個構造器，description實體變數繼承自Beverage
public Espresso(){
description="Espresso";
}
//最后，需要計算Espresso的價錢，現在不需要管調料的價錢，直接把Espresso的價格回傳即可
@Override
public double cost() {
return 1.99;
}
}
裝飾者實作類子類
我們已經完成了抽象組件(Beverage)，有了具體組件(Espresso等),也有了抽象裝飾者(CondimentDecorator)，現在， 我們就來實作具體裝飾者；
先從摩卡(Mocha)下手：
//摩卡是一個裝飾者，所以讓它擴展自CondimentDecorator，別忘了，CondimentDecorator擴展自Beverage
public class Mocha extends CondimentDecorator{
public Mocha(Beverage beverage){
this.beverage=beverage;//該類繼承了CondimentDecorator中的Beverage實體變數；來持有正在包裹的飲料
}
//回傳加入調料后的描述
@Override
public String getDescription() {
return beverage.getDescription()+",Mocha";
}
//回傳裝飾后的價格
//首先呼叫委托給正在裝飾的物件，計算價格；然后把摩卡價格添上去，
@Override
public double cost() {
return 0.20+beverage.cost();
}
}
Whip（奶泡）
public class Whip extends CondimentDecorator{
public Whip(Beverage beverage){
this.beverage=beverage;
}
@Override
public String getDescription() {
return beverage.getDescription()+",Whip";
}
@Override
public double cost() {
return 0.10+beverage.cost();
}
}
測驗
class StarbuzzCoffee{
public static void main(String arg[]){
//不加調料的濃縮咖啡
Beverage beverage1=new Espresso();
System.out.println(beverage1.getDescription()+"$"+beverage.cost());
//雙倍摩卡咖啡加奶泡
Beverage beverage2=new DarkRoast();
beverage2 = new Mocha(beverage2);
beverage2 = new Whip(beverage2);
System.out.println(beverage2.getDescription()+"$"+beverage.cost());
}
}
真實世界的裝飾者：Java I/O
裝飾java.io類
總結
OO原則：
封裝變化
組合優于繼承，
針對介面編程，而不是針對實作編程，
為互動物件之間的松耦合設計而努力，
類應該對擴展開放，對修改關閉，【讓關閉的部分和新擴展的部分隔離，】
裝飾者模式：給物件動態附加額外的責任，對于擴展功能，除了子類化之外,裝飾者提供了彈性的替代做法，
問題：
引入裝飾者會增加實體化組件所需代碼的復雜度，
一旦用了裝飾者，不只要實體化組件，還要把它包裹進裝飾者中，誰知道有幾個裝飾者，
要點
1.繼承是擴展形式之一，但未必是達到彈性設計的最佳方式，在我們的設計中，應該允許行為可以被擴展，而無需修改已有代碼，
2.組合和委托經常可以用來在運行時添加新行為，
3.裝飾者模式提供了子類化擴展行為的替代品，
4.裝飾者模式涉及一群裝飾者類，這些類用來包裝具體組件，
5.裝飾者類反映了它們所裝飾的組件型別(事實上，它們和所裝飾的組件型別相同，都經過了繼承或介面實作)，
6.裝飾者通過在對組件的方法呼叫之前(或/和之后，甚至在那一刻)添加功能改變其組件的行為，(關鍵點)
7.你可以用任意數目的裝飾者來包裹一個組件，
8.裝飾者一般對組件的客戶是透明的，除非客戶依賴于組件的具體型別，
9.裝飾者會導致設計中出現許多小物件，過度使用會讓代碼變得復雜，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/550227.html
標籤：其他
上一篇：03裝飾者模式