組合模式（ Composite ） - 結構型模式

組合模式是將對象之間的關系以數據結構中的 2 叉樹表現出來，使得客戶端將單純的元素與復雜元素同等看待，這樣的話使得用戶在操作不同的子類元素時可以和根節點元素一樣操作，在透明模式下即根元素和葉元素公用同一個接口達到共同的結果。組合模式就是解決部分與整體的關系的一種模式。

如在項目開發中遇到這樣的一個需求，要求羅列出系統中所有職責崗位上的用戶信息（職員名稱和薪水）。這是一個很簡單的需求，大多數程序員都能很輕易的寫出來。跟我們今天講的組合模式有聯系嗎？當然有啦。我們先來看看需求：

我們知道在一個公司里有很多崗位比如（總經理、副總經理、銷售部經理、財務部經理，銷售員，財務員。。。。）把公司里的所有職員按照所在崗位劃分出來，我們先來歸類，銷售員歸銷售部經理管，財務員歸財務部經理管，銷售部經理、財務部經理歸副總經理管，副總經理歸總經理管。這樣我們不難想想出這樣的結構圖：

<shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></path><lock v:ext="edit" aspectratio="t"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 163.5pt; HEIGHT: 276pt" type="#_x0000_t75" o:ole=""><imagedata src="file:///C:%5CDOCUME~1%5CWensi%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.emz" o:title=""></imagedata></shape> （圖 1 ）

依據圖 1 我們用面向對象的語言來描述他（這里我簡單的畫了一個關系圖并不是把所有公司部門都羅列出來，只是列舉了其中的一些列子）。

大家看了下面圖可能有點奇怪，怎么那么多部門都沒有了呢，只有一個 boss 和 employees 呢？

<shape id="_x0000_i1026" style="WIDTH: 414.75pt; HEIGHT: 378pt" type="#_x0000_t75"><imagedata src="file:///C:%5CDOCUME~1%5CWensi%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image003.png" o:title="EmployeeDiagram"></imagedata></shape>

首先：不管你是什么職位在哪個崗位在公司這個大背景下（容器）所有人都是公司的一個部分，所以我們抽象出一個職員的抽象類 Employee 。對于職員來說他們的上級主管都是他們的大 BOSS （老板）因為你是聽從他的調配的所以在我們這里只把他們抽象出來一個 Boss 和 Employees 類 Employees 是頁節點所以子集的因為職位上沒有什么是底層職工的下級，而 Boss 不同 0 到多個下屬 Employee （因為他的下屬有可能也是一個小 Boss 或是 Employees ）。

其次：每個部門都有負責人，對應每個崗位上的員工都有他們自己的 Boss

那么我們的目的就是把這些人一個個的劃分到指定的部分中去。我們定義一個接口 IComposite 他專門為 boss 收集他的子職員。（注意：這里我只在 boss 類這里繼承了這個接口規范而 Employees 并沒有此接口，這里我用了安全的組合模式，還有一種是 Employees 也繼承此接口這時這個模式是透明的組合模式用戶對用戶來說他們只需調用接口就可以不用估計是老板還是職員，但這也帶來了負面影響因為 Employees 是沒有下屬的所有這里的接口通常是不用實現的，所以可能在調用是出現運行時錯誤所以是不安全的，而前者只有 Boss 才有此接口所有這種模式是類型安全的組合模式，到底需要用哪一個這需要在實際開發中仔細考慮的。）

讓我們回頭看看這個 OOD 設計是否合理，我們依據我們第二章的設計模式原則來判定

1. 是否符合開閉原則

我們在新增一種 Employee 類型是如果他不是頁節點那么只需要實現 IComposite 接口用戶就可以直接使用所有對內是不要修改原有代碼，對外是可擴展的。

答案：符合

2. 是否符合里氏代換原則

Boss 和 Employees 都繼承與 Employee

答案：符合

3. 是否符合抽象原則

答案：符合

4. 是否符合迪米特法則

答案：符合

總結 ：組合模式

意圖 ：

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

動機 ：

客戶代碼過多的依賴于對象容器復雜的內部實現結構，對象容器內部實現結構（非抽象接口）的變化將引起客戶代碼的頻繁變化代碼的代碼維護和擴展的困難，我們需要將客戶代碼與復雜的對象容器結構解偶。

適用性 ：

l 想表示對象的部分 - 整體層次結構

l 希望用戶忽略組合對象與單個對象的不同，用戶將統一地使用組合結構中的所有對象。

結構 ：

<shape id="_x0000_i1027" style="WIDTH: 179.25pt; HEIGHT: 114pt" type="#_x0000_t75" alt=""><imagedata src="file:///C:%5CDOCUME~1%5CWensi%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image005.gif" o:><font face="Times New Roman" size="3"></font></imagedata></shape>

參與者 ：

l 抽象構件（ Component ）角色 （ IComposite ）

l 樹葉構件（ Leaf ）角色 ( Employees )

l 樹枝構件 (Boss)

Composite 模式的優點 ：

1. 客戶代碼不依賴復雜對象本身的結構變化

2. 用戶不需要特別關心復雜對象的具體結構只要等同于根對象操作

代碼 ：

http://download.csdn.net/source/360701

設計模式面面觀（11）：組合模式（Composite Pattern）-結構型模式