設計模式 裝飾者模式

2022-02-05 22:13:48 字數 1852 閱讀 7361

裝飾者(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()

}

vip服務

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 角色 定義乙個將要接收附...