設計模式 裝飾者模式

裝飾者（decorator）模式動態地將責任附加到物件上，若要擴充套件功能，裝飾者模式提供了比繼承更加有彈性的替代方案（來自 head first 設計模式）

component:元件介面，每個元件都可以單獨使用。也可以被裝飾者包裝起來使用。

concrete:具體的元件。擴充套件自元件介面

decorator:裝飾者介面。

concretedecorator:具體的裝飾者。

例子：需求是旅遊的景區需要買門票，但是門票**不只是原始的**。針對不同的情況會有不同的**變化。可能有國慶時候的折扣，也可以有許多態別的優惠券折扣，也可能在基本門票上進行更全面的服務，比如vip全天包遊服務。。。

門票主體

/**

* 元件介面
* @author
lzp * */
public
abstract
class
ticket 
//**計算
public
abstract
double
price();
}

public

class scenicticket extends
ticket
@override
public
double
price() 
}

/**

* 門票裝飾者抽象類
* @author
lzp * */
public
abstract
class ticketdecorator extends
ticket

國慶***

//

國慶優惠
public
class nationalday extends
ticketdecorator
@override
public
string getdescription() 
@override
public
double
price() 
}

//

優惠券public
class coupon extends
ticketdecorator
@override
public
string getdescription() 
@override
public
double
price() 
}

public

class vipservice extends
ticketdecorator
@override
public
string getdescription() 
@override
public
double
price() 
}

public

class
main 
}

裝飾者模式是在不改變原有介面的前提下增強物件的效能。

但是會產生比較多的裝飾者類。

設計模式 裝飾者模式

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

設計模式 裝飾者模式

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

設計模式 裝飾者模式

好幾天沒出部落格了，在學習android的一些新控制項的時候，用到了乙個模式，叫裝飾者模式，所以在此講講這個模式。模式，包含以下四個角色 1 抽象構件 component 角色 給出乙個抽象介面，以規範準備接收附加責任的物件。2 具體構件 concretecomponent 角色 定義乙個將要接收附...