Decorator裝飾模式是一種結構型模式,它主要是解決:過度地使用了繼承來擴充項物件的功能。就增加功能而言,Decorator模式比產生子類更為靈活。
Decorator裝飾模式是一種結構型模式,它主要是解決:“過度地使用了繼承來擴充項物件的功能”,由於繼承為類型引入的靜態特質,使得這種擴充方式缺乏靈活性;並且隨著子類的增多(擴充功能的增多),各種子類的組合(擴充功能的組合)會導致更多子類的膨脹(多繼承)。繼承為類型引入的靜態特質的意思是說以繼承的方式使某一類型要獲得功能是在編譯時間。所謂靜態,是指在編譯時間;動態,是指在運行時。GoF《設計模式》中說道:動態給一個對象添加一些額外的職責。就增加功能而言,Decorator模式比產生子類更為靈活。下面來看看Decorator模式的結構: 看這個結構好像不是很明白,下面我根據代碼講解一下這個結構。我想了一個情境:我們現在用的手機功能很多,我就用Decorator模式實現一下對某個手機的GSP和藍芽功能擴充。首先,我們需要一個手機的介面或者是抽象類別,我這裡就用抽象類別來實現,代碼如下:public abstract class AbstractCellPhone { public abstract string CallNumber(); public abstract string SendMessage();}AbstractCellPhone也就是結構圖中的Component,然後,我再來實現Nokia和Moto的手機類,這類要繼承AbstractCellPhone,也就是圖中ConcreteComponent類要繼承Component,實現代碼如下:public class NokiaPhone : AbstractCellPhone { public override string CallNumber() { return "NokiaPhone call sombody"; } public override string SendMessage() { return "NokiaPhone send a message to somebody"; } } public class MotoPhone : AbstractCellPhone { public override string CallNumber() { return "MotoPhone call sombody"; } public override string SendMessage() { return "MotoPhone send a message to somebody"; } } 接下來我需要一個Decorator介面或者抽象類別,實現代碼如下:public abstract class Decorator:AbstractCellPhone { AbstractCellPhone _phone; public Decorator(AbstractCellPhone phone) { _phone = phone; } public override string CallNumber() { return _phone.CallNumber(); } public override string SendMessage() { return _phone.SendMessage(); } }正如結構圖中,這個Decorator即繼承了AbstractCellPhone,又包含了一個私人的AbstractCellPhone的對象。這樣做的意義是:Decorator類又使用了另外一個Component類。我們可以使用一個或多個Decorator對象來“裝飾”一個Component對象,且裝飾後的對象仍然是一個Component對象。在下來,我要實現GSP和藍芽的功能擴充,它們要繼承自Decorator,代碼如下:public class DecoratorGPS : Decorator { public DecoratorGPS(AbstractCellPhone phone) : base(phone) { } public override string CallNumber() { return base.CallNumber() + " with GPS"; } public override string SendMessage() { return base.SendMessage() + " with GPS"; } } public class DecoratorBlueTooth : Decorator { public DecoratorBlueTooth(AbstractCellPhone phone) : base(phone) { } public override string CallNumber() { return base.CallNumber() + " with BlueTooth"; } public override string SendMessage() { return base.SendMessage() + " with BlueTooth"; } }最後,用用戶端程式驗證一下:static void Main(string[] args) { AbstractCellPhone phone = new NokiaPhone(); Console.WriteLine(phone.CallNumber()); Console.WriteLine(phone.SendMessage()); DecoratorGPS gps = new DecoratorGPS(phone); //add GSP Console.WriteLine(gps.CallNumber()); Console.WriteLine(gps.SendMessage()); DecoratorBlueTooth bluetooth = new DecoratorBlueTooth(gps); //add GSP and bluetooth Console.WriteLine(bluetooth.CallNumber()); Console.WriteLine(bluetooth.SendMessage()); Console.Read(); }執行結果:NokiaPhone call sombodyNokiaPhone send a message to somebodyNokiaPhone call sombody with GPSNokiaPhone send a message to somebody with GPSNokiaPhone call sombody with GPS with BlueToothNokiaPhone send a message to somebody with GPS with BlueTooth 從執行的結果不難看出擴充功能已被添加。最後再說說Decorator裝飾模式的幾點要點:1、通過採用組合、而非繼承的手法,Decorator模式實現了在運行時動態擴充項物件功能的能力,而且可以根據需要擴充多個功能。避免了單獨使用繼承帶來的“靈活性差”和“多子類衍生問題”。2、Component類在Decorator模式中充當抽象介面的角色,不應該去實現具體的行為。而且Decorator類對於Component類應該透明——換言之Component類無需知道Decorator類,Decorator類是從外部來擴充Component類的功能。3、Decorator類在介面上表現為is-a Component的繼承關係,即Decorator類繼承了Component類所具有的介面。但在實現上又表現為has-a Component的組合關係,即Decorator類又使用了另外一個Component類。我們可以使用一個或多個Decorator對象來“裝飾”一個Component對象,且裝飾後的對象仍然是一個Component對象。(在這裡我想談一下我的理解:當我們執行個體化一個Component對象後,要給這個對象擴充功能,這時我們把這個Component對象當作參數傳給Decorator的子類的建構函式——也就是擴充方法的功能類。對於參考型別傳參時,實際上只是傳遞對象的地址,這樣,在功能擴充是,操作的應該是同一個對象)4、Decorator模式並非解決“多子類衍生的多繼承”問題,Decorator模式應用的要點在於解決“主體類在多個方向上的擴充功能”——是為“裝飾”的含義。Decorator是在運行時對功能進行組合。