對象容器的問題

　　在面向?qū)ο笙到y(tǒng)中，我們常會(huì)遇到一類具有“容器”特征的對象——即它們在充當(dāng)對象的同時(shí)，又是其他對象的容器。

　　如果我們要對這樣的對象容器進(jìn)行處理：

　　上面是客戶代碼，客戶代碼里面必須要知道對象的結(jié)構(gòu)，有可能還要使用遞歸的方法來處理這個(gè)對象，這樣寫耦合性就比較高。客戶代碼如果能只和IBox發(fā)生依賴就很好了，但是現(xiàn)在它還和ContainerBox和SingleBox發(fā)生了依賴，這樣內(nèi)部實(shí)現(xiàn)的細(xì)節(jié)就暴露給了外界，并且和外界產(chǎn)生了依賴關(guān)系。

　　動(dòng)機(jī)（Motivation）

　　上述描述的問題根源在于：客戶代碼過多地依賴于對象容器復(fù)雜的內(nèi)部實(shí)現(xiàn)結(jié)構(gòu)，對象容器內(nèi)部實(shí)現(xiàn)結(jié)構(gòu)（而非抽象接口）的變化將引起客戶代碼的頻繁變化，帶來了代碼的維護(hù)性、擴(kuò)展性等弊端。如何將“客戶代碼與復(fù)雜的對象容器結(jié)構(gòu)”解耦？讓對象容器自己來實(shí)現(xiàn)自身的復(fù)雜結(jié)構(gòu)，從而使得客戶代碼就像處理簡單對象一樣來處理復(fù)雜的對象容器？

　　意圖（Intent）

　　將對象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)。Composite使得用戶對單個(gè)對象和組合對象的使用具有一致性。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《設(shè)計(jì)模式》GoF

　　例說Composite應(yīng)用

　　以前面的例子為例

　　改進(jìn)的方案

　　期望的客戶代碼：

　　接口和SingleBox代碼都不變

　　ContainerBox代碼變化

　　這樣做ContainerBox里面的Process方法就不用判斷是否是ContainerBox還是SingleBox，因?yàn)樗鼈儓?zhí)行的方法名字都叫做Process。而且客戶代碼也只用調(diào)用box的Process方法即可。但是這里還有一個(gè)問題，客戶代碼訪問不了ContainerBox的Add和Remove方法，因?yàn)镮Box接口里沒有定義。

　　為了解決這個(gè)問題，我們可以選擇在IBox接口里添加兩個(gè)方法Add和Remove，然后SingleBox的Add和Remove方法什么都不做或者拋出異常。

　　但這樣的處理方法也和理想的方法有點(diǎn)差距，因?yàn)镮Box這個(gè)類并不符合我們類的單一職責(zé)原則，它有SingleBox和ContainerBox二者的職責(zé)，因此SingleBox對于Add和Remove也比較不好處理。但是總的來說，我們還是完成了客戶代碼的解耦工作。

　　我們看看整個(gè)代碼的結(jié)構(gòu)，ContainerBox里面包含了很多IBox，這些IBox有的是ContainerBox，有的也是SingleBox，因此它很像一個(gè)樹形的結(jié)構(gòu)。

　　結(jié)構(gòu)（Structure）

　　Component抽象類或者接口對應(yīng)之前例子中的IBox，Leaf對應(yīng)SingleBox，Composite對應(yīng)ContainerBox。客戶代碼只依賴于Component抽象類或者結(jié)構(gòu)，這正是我們期望的目的。

　　Composite模式的幾個(gè)要點(diǎn)

　　Composite模式采用樹形結(jié)構(gòu)來實(shí)現(xiàn)普遍存在的對象容器，從而將“一對多”的關(guān)系轉(zhuǎn)化為“一對一”的關(guān)系，使得客戶代碼可以一致地處理對象和對象容器，無需關(guān)心處理的是單個(gè)的對象，還是組合的對象容器。

　　將“客戶代碼與復(fù)雜的對象容器結(jié)構(gòu)”解耦是Composite模式的核心思想，解耦之后，客戶代碼將與純粹的抽象接口——而非對象容器的復(fù)雜內(nèi)部實(shí)現(xiàn)結(jié)構(gòu)——發(fā)生依賴關(guān)系，從而更能“應(yīng)對變化”。

　　Composite模式中，是將“Add和Remove等和對象容器相關(guān)的方法”定義在“表示抽象對象的Component類”中，還是將其定義在“表示對象容器的Composite類”中，是一個(gè)關(guān)乎“透明性”和“安全性”的兩難問題，需要仔細(xì)權(quán)衡。這里有可能違背面向?qū)ο蟮?ldquo;單一職責(zé)原則”，但是對于這種特殊結(jié)構(gòu)，這又是必須付出的代價(jià)。ASP.NET控件的實(shí)現(xiàn)在這方面為我們提供了一個(gè)很好的示范。

　　Composite模式在具體實(shí)現(xiàn)中，可以讓父對象中的子對象反向追朔；如果父對象有頻繁的遍歷需求，可使用緩存技巧來改善效率。

　　.NET框架中的Composite應(yīng)用

　　ASP.NET中的Panel對象就是一個(gè)Composite對象，而Button對象就是Leaf對象。Button和Panel都繼承自System.Web.UI.Control類。

　　它實(shí)際上是在Panel里面加了一個(gè)Controls屬性，然后Controls屬性是一個(gè)集合屬性，它有Add和Remove方法。這樣我們的IBox也可以改為：

　　在ASP.NET中就是這樣，每一個(gè)控件都有Controls屬性，也就是說每個(gè)控件都是一種容器控件（除了LiteralControl）。這種方式把我們對安全性的擔(dān)憂，統(tǒng)統(tǒng)放到容器（即ASP.NET中的Controls，以及例子中的Boxes）中去處理。

it知識庫：C#面向?qū)ο笤O(shè)計(jì)模式縱橫談：Composite 組合模式，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。