设计模式学习笔记（十）——Decorator装饰模式
Decorator裝飾模式是一種結(jié)構(gòu)型模式，它主要是解決：“過度地使用了繼承來擴展對象的功能”，由于繼承為類型引入的靜態(tài)特質(zhì)，使得這種擴展方式缺乏靈活性；并且隨著子類的增多（擴展功能的增多），各種子類的組合（擴展功能的組合）會導(dǎo)致更多子類的膨脹（多繼承）。繼承為類型引入的靜態(tài)特質(zhì)的意思是說以繼承的方式使某一類型要獲得功能是在編譯時。所謂靜態(tài)，是指在編譯時；動態(tài)，是指在運行時。
GoF《設(shè)計模式》中說道：動態(tài)的給一個對象添加一些額外的職責。就增加功能而言，Decorator模式比生成子類更為靈活。
下面來看看Decorator模式的結(jié)構(gòu)：
<?XML:NAMESPACE PREFIX = V /><?XML:NAMESPACE PREFIX = O />
看這個結(jié)構(gòu)好像不是很明白，下面我根據(jù)代碼講解一下這個結(jié)構(gòu)。我想了一個場景：我們現(xiàn)在用的手機功能很多，我就用Decorator模式實現(xiàn)一下對某個手機的GSP和藍牙功能擴展。
首先，我們需要一個手機的接口或者是抽象類，我這里就用抽象類來實現(xiàn)，代碼如下：
public abstract class AbstractCellPhone
??? {
??????? public abstract string CallNumber();
??????? public abstract string SendMessage();
}
AbstractCellPhone也就是結(jié)構(gòu)圖中的Component，然后，我再來實現(xiàn)Nokia和Moto的手機類，這類要繼承AbstractCellPhone，也就是圖中ConcreteComponent類要繼承Component，實現(xiàn)代碼如下：
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接口或者抽象類，實現(xiàn)代碼如下：
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();
??????? }
? }
正如結(jié)構(gòu)圖中，這個Decorator即繼承了AbstractCellPhone，又包含了一個私有的AbstractCellPhone的對象。這樣做的意義是：Decorator類又使用了另外一個Component類。我們可以使用一個或多個Decorator對象來“裝飾”一個Component對象，且裝飾后的對象仍然是一個Component對象。在下來，我要實現(xiàn)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 <?XML:NAMESPACE PREFIX = ST1 />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();
??? ?}
執(zhí)行結(jié)果：
NokiaPhone call sombody
NokiaPhone send a message to somebody
NokiaPhone call sombody with GPS
NokiaPhone send a message to somebody with GPS
NokiaPhone call sombody with GPS with BlueTooth
NokiaPhone send a message to somebody with GPS with BlueTooth
?
從執(zhí)行的結(jié)果不難看出擴展功能已被添加。最后再說說Decorator裝飾模式的幾點要點：
1、通過采用組合、而非繼承的手法，Decorator模式實現(xiàn)了在運行時動態(tài)的擴展對象功能的能力，而且可以根據(jù)需要擴展多個功能。避免了單獨使用繼承帶來的“靈活性差”和“多子類衍生問題”。
2、Component類在Decorator模式中充當抽象接口的角色，不應(yīng)該去實現(xiàn)具體的行為。而且Decorator類對于Component類應(yīng)該透明——換言之Component類無需知道Decorator類，Decorator類是從外部來擴展Component類的功能。
3、Decorator類在接口上表現(xiàn)為is-a Component的繼承關(guān)系，即Decorator類繼承了Component類所具有的接口。但在實現(xiàn)上又表現(xiàn)為has-a Component的組合關(guān)系，即Decorator類又使用了另外一個Component類。我們可以使用一個或多個Decorator對象來“裝飾”一個Component對象，且裝飾后的對象仍然是一個Component對象。（在這里我想談一下我的理解：當我們實例化一個Component對象后，要給這個對象擴展功能，這時我們把這個Component對象當作參數(shù)傳給Decorator的子類的構(gòu)造函數(shù)——也就是擴展方法的功能類。對于引用類型傳參時，實際上只是傳遞對象的地址，這樣，在功能擴展是，操作的應(yīng)該是同一個對象）
4、Decorator模式并非解決“多子類衍生的多繼承”問題，Decorator模式應(yīng)用的要點在于解決“主體類在多個方向上的擴展功能”——是為“裝飾”的含義。Decorator是在運行時對功能進行組合。
轉(zhuǎn)載于:https://www.cnblogs.com/wayne-ivan/archive/2006/10/18/532298.html
總結(jié)
以上是生活随笔為你收集整理的设计模式学习笔记（十）——Decorator装饰模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 认识httphandler
- 下一篇： 轻松实现Access数据导入Oracle