結合專案例項 回顧傳統設計模式(三)裝飾者模式

2021-09-21 04:58:35 字數 2658 閱讀 1826

說到這個模式的專案例項 蟲子也滿頭疼的 所謂裝飾者模式說白了動態將職責附加到物件上。如果你在專案某個場景中需要功能擴充套件根據基類衍生出非常多的子類,那麼裝飾者模式無疑是很好的。不過其實在實際的專案中,往往大家不直接衍生子類,而是通過組合的方式,根據邏輯講各種擴充套件疊加來,對外公布的只是乙個標籤乙個殼而已。

所以這個章節,蟲子就虛構乙個例項了。還拿電商來說、點券贈品系統。

背景:1.所有點券、優惠券、贈品券、積分繼承同乙個基類 基類券

2.不用種類的券可以混合搭配

3.積分根據不同的場景可以配置不同的規則

4.公升級禮券在上層禮券基礎上新增

一般情況下 大家可以就這樣設計了

//////

基卡///

public

abstract

class basecard

//////

點卡a///

public

class carda : basecard

public

override

double cost()

}

//////

優惠券a

///

public

class couponsa : basecard

public

override

double cost()

}

//////

優惠券b

///

public

class couponsb : basecard

public

override

double cost()

}

//////

國慶禮券

///

public

class gqcard : basecard

public

override

double cost()

}

//////

國慶公升級a等禮券

///

public

class gqacard : basecard

public

override

double cost()

} 設計模式的原則是類應該對擴充套件開放對修改關閉,而上述設計在禮券公升級種類越來越多的情況下並且現有的禮券已經頻繁更新的話 對於龐大的禮券系統肯定是不理想的

那麼我們換個思路

//////

基卡///

public

abstract

class basecard

//////

點卡a///

public

class carda : baseoupons

public

override

double cost()

}

//////

優惠券a

///

public

class couponsa : baseoupons

public

override

double cost()

}

//////

優惠券b

///

public

class couponsb : baseoupons

public

override

double cost()

}

//////

基類禮券

///

public

class baseoupons : basecard

public baseoupons()

public

override

double cost()

else

}}

讓我們看看裝飾者模式的強大

basecard a = 

new baseoupons();

a = 

new carda(a);

a = 

new couponsa(a);

a = 

new couponsb(a);

console.writeline(

"國慶禮券由

"+a.decription+

"組成");

console.writeline(a.cost().tostring());

basecard b = 

new carda(a);

console.writeline(

"國慶公升級禮券由

" + b.decription + 

"組成");

總結:繼承屬於擴充套件形式之一,但不見得是達到彈性設計的最佳方式,在我們的設計當中應該允許行為可以被擴充套件,而無需修改現有的**。就如上述的例子裝飾者模式也可以讓我們擴充套件行為。不過裝飾者模式也有缺點,它會導致設計**現許多小物件,如果過度使用,會讓程式變得很複雜。

結合專案例項 回顧傳統設計模式(六)命令模式

命令模式將請求封裝成物件,以便使用不同的請求 佇列或者日誌來引數化其他物件。命令模式也支援可撤銷的操作。使用者程式在使用的時候,只與該命令物件打交道,而不用與一類物件打交道,降低了耦合性,提高了程式設計的靈活性。我們還是那資料庫操作為例 public class dbinstance public ...

結合專案例項 回顧傳統設計模式(二)觀察者模式

觀察者模式現在用的不是很多 重點看下它的設計思想 ok 下面繼續 訊息中心的那點事 資料中心 public class messagedata 上述情況在soa體系架構中凸顯比較嚴重,基本上資料中心作為基站程式不適合版本經常更新 那麼這和一對多得關係有何關聯 利用觀察者模式,資料中心是具體狀態的物件...

結合專案例項 回顧傳統設計模式(二)觀察者模式

觀察者模式現在用的不是很多 重點看下它的設計思想 ok 下面繼續 訊息中心的那點事 資料中心 public class messagedata 上述情況在soa體系架構中凸顯比較嚴重,基本上資料中心作為基站程式不適合版本經常更新 那麼這和一對多得關係有何關聯 利用觀察者模式,資料中心是具體狀態的物件...