我的設計模式筆記 裝飾者模式

裝飾者模式要求」主體「（被裝飾者/圖中的concrete component）和「裝飾」(圖中的base decorator)都要繼承同乙個介面（圖中的component）。其中「主體」和「裝飾」可以直接是該介面的實現，並且裝飾器（decorator）與介面是聚合關係。聚合關係（component聚合到裝飾器上）就意味著，裝飾器的構造方法需要介面作為引數傳入。

實現步驟

主體類/裝飾類分別實現介面方法

將主體類聚合到裝飾類中（即將主題類作為引數傳入裝飾類中的構造方法中）

客戶端建立完主體類後，可以在外層包裹任意層裝飾類，如下所示

//部件類

public
abstract
class
drink
public
void
setprice
(float price)
public string getname()
public
void
setname
(string name)
public
abstract
float
cost()
;public
abstract string desc()
;}//具體部件
public
class
coffee
extends
drink
@override
public string desc()
}//基礎裝飾器
public
class
decorator
extends
drink
@override
public
float
cost()
@override
public string desc()
}//具體裝飾器1
public
class
milk
extends
decorator
}//具體裝飾器2
public
class
sugar
extends
decorator
}//使用者呼叫
public
class
client
}

設計模式筆記（三） 裝飾者模式

裝飾者模式 decorator pattern 動態地將責任附加到物件上。若要擴充套件功能，裝飾者提供了比繼承更有彈性的替代方案。簡單點說，裝飾者可以裝飾 也就是在原來功能的基礎上再擴充套件其功能 被裝飾者。乙個被裝飾者可以被多個裝飾者裝飾，或者被相同的裝飾者裝飾多次，是不是很靈活啊。而這就要求裝飾...

設計模式 裝飾者模式

public abstract class beverage public abstract double cost public abstract class condimentdecorator extends beverage public class darkroast extends be...

設計模式 裝飾者模式

沒什麼特別的，之前看懂了，這次自己再複述一下。畢竟把別人講懂了才是真的懂了。主要參考了head first 設計模式。例子講述的是在為星巴克咖啡的製作訂單的情況，比如客人點了飲料，那麼系統會自動算出 不知道是我沒有體會到，還是這個例子不太合適，算出 那麼簡單的事還需要用到類？不過不影響我們思考裝飾者...