设计模式08: Composite 组合模式(结构型模式)
Composite 組合模式(結構型模式)
對象容器的問題
在面向對象系統中,我們常會遇到一類具有“容器”特征的對象——即他們在充當對象的同時,又是其他對象的容器。
如果我們要對這樣的對象進行處理:
class App {public static void Main(){IBox box=Factory.GetBox();if(box is ContainerBox){box.Process();ArrayList list=((ContainerBox)box).GetBoxes();...//將面臨比較復雜的遞歸處理 }else if(box is SingleBox){box.Process();}} }
動機(Motivation)
上述問題的根源在于:客戶代碼過多地依賴于對象容器復雜的內部實現結構,對象容器內部實現結構(而非抽象接口)的變化將引起客戶代碼的頻繁變化,帶來了代碼的維護性、擴展性等弊端。
如何將“客戶代碼與復雜對象容器結構”解耦?讓對象容器自己來實現自身的復雜結構,從而使得客戶代碼就像處理簡單對象一樣來處理復雜的對象容器?
意圖(Intent)
將對象組合成屬性結構以表示“部分-整體”的層次結構。Composite使得用戶對單個對象和組合對象的使用具有一致性。——《設計模式》GoF
可以將上面代碼改為:
?
Composite模式的幾個要點
Composite模式采用樹形結構來實現普遍存在的對象容器,從而將“一對多”的關系轉化為“一對一”的關系,使得客戶代碼可以一致地處理對象和對象容器,無需關心處理的是單個的對象,還是組合的對象容器。
將“客戶代碼與復雜度對象容器結構”解耦是Composite模式的核心思想,解耦之后,客戶代碼將與純粹的抽象接口——而非對象容器的復雜內部實現結構——發生依賴關系,從而更能“應對變化”。
Composite模式中,是將“Add和Remove等和對象容器相關的方法”定義在“表示抽象對象的”IBox類中,還是將其定義在“表示對象容器的ContainerBox類”中,是一個關乎“透明性”和“安全性”的兩難問題,需要仔細權衡。這里可能違背面向對象的“單一職責原則”,但是對于這種特殊結構,這又是必須付出的代價。ASP.NET控件的實現在這方面為我們提供了一個很好的示范。
Composite模式在具體實現中,可以讓父對象中的子對象反向追溯;如果父對象有頻繁的遍歷需求,可使用緩存技巧來改善效率。
轉載于:https://www.cnblogs.com/jesselzj/p/4722544.html
總結
以上是生活随笔為你收集整理的设计模式08: Composite 组合模式(结构型模式)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: canvas图像保存
- 下一篇: mysql重置密码