Java設計模式裝飾者模式

愉快的工作又開始了。leader安排了乙個新的任務，給乙個酸奶店的點單軟體增加新的功能。

這個程式的原來所有的酸奶都繼承於乳酪類（cheese）

public
abstract
class
cheese 
public
abstract
intprice();

所有具體的酸奶繼承乳酪類並重寫**price方法，以原味酸奶和宮廷酸奶為例：

public
class
original
extends
cheese
@override
public
intprice() 
}public
class
court
extends
cheese
@override
public
intprice() 
}

這樣的話直接呼叫實現類的introduce和price就可以得到名字和**了。

但是隨著酸奶店的規模越來越大，品種也越來越多，出現了一些新的品種的酸奶和配料，比如：士多啤梨，奧利奧，櫻桃。這些配料和酸奶進行搭配然後計算總共的**和名稱。

稍微思考一下，可能會有人選擇這樣寫**，以原味酸奶加士多啤梨為例：

public
class
originalstrawberry
extends
cheese
@override
public
intprice() 
}

這樣看起來，似乎並沒有什麼不妥，但是仔細想一想，酸奶加配料這樣的組合有多少種可能呢？如果每一種可能都要寫出來乙個類的話，那麼簡直要類**，並且如果任何乙個酸奶或者配料更改了**的話，那麼所有關聯類都需要修改，如果顧客想要雙倍的士多啤梨呢？或者士多啤梨加櫻桃呢？這樣寫下去簡直是***的方法。

設計原則之一：類應該對擴充套件開發，對修改關閉。比如說對於一些我們經過測試沒有問題的**，原則上不應該修改源**，而應該在源**基礎之上進行擴充套件。

如果我們這樣設計**是不是更好一點，還是以原味酸奶加士多啤梨為例：我們先把一杯原味酸奶作為主體（被修飾者），用士多啤梨作為修飾者修飾主體。就是先得到乙個原味酸奶的物件，用士多啤梨物件修飾它，然後呼叫price方法將士多啤梨的價錢加上去。

這樣的做法可以動態的將乳酪和配料松耦合的搭配在一起。所以先把系統分為乳酪和配料兩個部分。

public abstract class batching extends

cheese

士多啤梨的實現類如下：

public
class
strawberry
extends
batching 
@override
public
intprice() 
@override
public string introduce() 
}

櫻桃的實現類如下：

public
class
cherry
extends
batching
@override
public string introduce() 
@override
public
intprice() 
}

以原味酸奶加士多啤梨為例：

public
class
test 
}

輸出結果：original,strawberry12

Java設計模式 裝飾者模式