對象容器的問題

　　在面向對象系統中，我們常會遇到一類具有“容器”特征的對象——即它們在充當對象的同時，又是其他對象的容器。

　　如果我們要對這樣的對象容器進行處理：

　　上面是客戶代碼，客戶代碼里面必須要知道對象的結構，有可能還要使用遞歸的方法來處理這個對象，這樣寫耦合性就比較高。客戶代碼如果能只和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模式在具體實現中，可以讓父對象中的子對象反向追朔；如果父對象有頻繁的遍歷需求，可使用緩存技巧來改善效率。

　　.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）中去處理。