設計模式之裝飾模式篇(Decorator)
如果我們對自己所居住的房間不滿意的時候,我們往往是通過裝修的方式來使我們的房間變的漂亮起來。而不是重新建一個房間。而且經過裝修的屋子仍讓是原來的屋子,本質不會變,但它的確變漂亮了,滿足了我們的美的需求。從投入來看,裝修比重新建設顯然要便宜的多! 在軟件設計里面,此類情形的設計既可以采用裝飾模式(Decorator)來完成。
2.概念與模式
裝飾模式(Decorator)也叫包裝器模式(Wrapper)。GOF在《設計模式》一書中給出的定義為:動態地給一個對象添加一些額外的職責。就增加功能來說,Decorator模式相比生成子類更為靈活。
裝飾模式的實現類關系圖為:
1) 抽象構件角色(Component):定義一個抽象接口,以規范準備接收附加責任的對象。
2) 具體構件角色(Concrete Component):這是被裝飾者,定義一個將要被裝飾增加功能的類。
3) 裝飾角色(Decorator):持有一個構件對象的實例,并定義了抽象構件定義的接口。
4) 具體裝飾角色(Concrete Decorator):負責給構件添加增加的功能。
3.應用實例
一部手機,在其接受到來電的時候,會發出聲音來提醒主人。而現在我們需要為該手機添加一項功能,在接收來電的時候,產生震動,而令一部更加高級,不僅發聲,而且振動,而且有燈光閃爍。
用裝飾模式來解決這個問題的類關系圖為:
相關文件為:
運行結果:
四、應用環境
GOF書中給出了以下使用情況:
1) 在不影響其他對象的情況下,以動態、透明的方式給單個對象添加職責。
2) 處理那些可以撤消的職責。
3) 當不能采用生成子類的方法進行擴充時。一種情況是,可能有大量獨立的擴展,為支持每一種組合將產生大量的子類,使得子類數目呈爆炸性增長。另一種情況可能是因為類定義被隱藏,或類定義不能用于生成子類。
來分析下手機的使用是屬于哪種情況。首先實現了比靜態繼承更加靈活的方式,動態的增加功能。試想為手機的所有實現類通過繼承來增加一個功能,意味著要添加不少的功能類似的子類,這明顯是不太合適的。
而且,這就避免了高層的類具有太多的特征。
五、透明和半透明
對于面向接口編程,應該盡量使客戶程序不知道具體的類型,而應該對一個接口操作。這樣就要求裝飾角色和具體裝飾角色要滿足Liskov替換原則。
六、其它 采用Decorator模式進行系統設計往往會產生許多看上去類似的小對象,這些對象僅僅在他們相互連接的方式上有所不同,而不是它們的類或是它們的屬性值有所不同。盡管對于那些了解這些系統的人來說,很容易對它們進行定制,但是很難學習這些系統,排錯也很困難。這是GOF提到的裝飾模式的缺點,你能體會嗎?他們所說的小對象我認為是指的具體裝飾角色。這是為一個對象動態添加功能所帶來的副作用。
源碼下載: Decorator.rar
出處:http://jillzhang.cnblogs.com/
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。






}
浙公網安備 33010602011771號