|
|
對象容器的問題
在面向對象系統中，我們常會遇到一類具有“容器”特征的對象——即它們在充當對象的同時，又是其他對象的容器。
如果我們要對這樣的對象容器進行處理：
上面是客戶代碼，客戶代碼里面必須要知道對象的結構，有可能還要使用遞歸的方法來處理這個對象，這樣寫耦合性就比較高。客戶代碼如果能只和IBox發生依賴就很好了，但是現在它還和ContainerBox和SingleBox發生了依賴，這樣內部實現的細節就暴露給了外界，并且和外界產生了依賴關系。
動機（Motivation）
上述描述的問題根源在于：客戶代碼過多地依賴于對象容器復雜的內部實現結構，對象容器內部實現結構（而非抽象接口）的變化將引起客戶代碼的頻繁變化，帶來了代碼的維護性、擴展性等弊端。如何將“客戶代碼與復雜的對象容器結構”解耦？讓對象容器自己來實現自身的復雜結構，從而使得客戶代碼就像處理簡單對象一樣來處理復雜的對象容器？
意圖（Intent）
將對象組合成樹形結構以表示“部分-整體”的層次結構。Composite使得用戶對單個對象和組合對象的使用具有一致性。
——《設計模式》GoF
例說Composite應用
以前面的例子為例
改進的方案
期望的客戶代碼：
接口和SingleBox代碼都不變
ContainerBox代碼變化
這樣做ContainerBox里面的Process方法就不用判斷是否是ContainerBox還是SingleBox，因為它們執行的方法名字都叫做Process。而且客戶代碼也只用調用box的Process方法即可。但是這里還有一個問題，客戶代碼訪問不了ContainerBox的Add和Remove方法，因為IBox接口里沒有定義。
為了解決這個問題，我們可以選擇在IBox接口里添加兩個方法Add和Remove，然后SingleBox的Add和Remove方法什么都不做或者拋出異常。
但這樣的處理方法也和理想的方法有點差距，因為IBox這個類并不符合我們類的單一職責原則，它有SingleBox和ContainerBox二者的職責，因此SingleBox對于Add和Remove也比較不好處理。但是總的來說，我們還是完成了客戶代碼的解耦工作。
我們看看整個代碼的結構，ContainerBox里面包含了很多IBox，這些IBox有的是ContainerBox，有的也是SingleBox，因此它很像一個樹形的結構。
結構（Structure）
Component抽象類或者接口對應之前例子中的IBox，Leaf對應SingleBox，Composite對應ContainerBox。客戶代碼只依賴于Component抽象類或者結構，這正是我們期望的目的。
Composite模式的幾個要點
Composite模式采用樹形結構來實現普遍存在的對象容器，從而將“一對多”的關系轉化為“一對一”的關系，使得客戶代碼可以一致地處理對象和對象容器，無需關心處理的是單個的對象，還是組合的對象容器。
將“客戶代碼與復雜的對象容器結構”解耦是Composite模式的核心思想，解耦之后，客戶代碼將與純粹的抽象接口——而非對象容器的復雜內部實現結構——發生依賴關系，從而更能“應對變化”。
Composite模式中，是將“Add和Remove等和對象容器相關的方法”定義在“表示抽象對象的Component類”中，還是將其定義在“表示對象容器的Composite類”中，是一個關乎“透明性”和“安全性”的兩難問題，需要仔細權衡。這里有可能違背面向對象的“單一職責原則”，但是對于這種特殊結構，這又是必須付出的代價。ASP.NET控件的實現在這方面為我們提供了一個很好的示范。
Composite模式在具體實現中，可以讓父對象中的子對象反向追朔；如果父對象有頻繁的遍歷需求，可使用緩存技巧來改善效率。
ASP.NET中的Panel對象就是一個Composite對象，而Button對象就是Leaf對象。Button和Panel都繼承自System.Web.UI.Control類。
它實際上是在Panel里面加了一個Controls屬性，然后Controls屬性是一個集合屬性，它有Add和Remove方法。這樣我們的IBox也可以改為：
在ASP.NET中就是這樣，每一個控件都有Controls屬性，也就是說每個控件都是一種容器控件（除了LiteralControl）。這種方式把我們對安全性的擔憂，統統放到容器（即ASP.NET中的Controls，以及例子中的Boxes）中去處理。
it知識庫：C#面向對象設計模式縱橫談：Composite 組合模式，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
