關鍵字：演算法工程的類圖，架構分析，設計模式，組合模式 首先，上一個我剛完成的針對上一篇 "Knowledge_SPA——精研查找演算法" 文中使用的工程，所畫的類圖，由此來分析它的架構。如下圖所示： 我們這個工程中使用到了很多設計模式，考慮到了不少設計原則，這一篇又回到了設計模式的學習路線，那麼可以勉 ...
關鍵字：演算法工程的類圖，架構分析，設計模式，組合模式
首先，上一個我剛完成的針對上一篇Knowledge_SPA——精研查找演算法文中使用的工程，所畫的類圖，由此來分析它的架構。如下圖所示：
我們這個工程中使用到了很多設計模式，考慮到了不少設計原則，這一篇又回到了設計模式的學習路線，那麼可以勉強使用這個工程來分析一下組合模式。
組合模式：將對象組合成樹形結構以表示“部分-整體”的層次結構。
分角色
如果要使用組合模式，首先要將你的系統區分出幾個角色：
- 主幹
- 葉子結點
- 樹枝
這三個角色是什麼意思呢？
從上面定義可知，對象之間通過組合關係形成樹形結構。那麼從這個樹形結構中去將這三個角色區分出來並不難。
我們結合演算法的工程來舉例分析，由於還有其他架構在裡面，這裡我們只分析ST這一支。
- 主幹是ST
- 葉子結點是SequentialSearchST, BinarySearchST, BST, RedBlackBST, ChainHashST, ProbeHashST
- 樹枝是SFunction
角色的活
角色區分完畢以後，要給他們安排具體任務，
- 主幹就是最終提供給客戶端調用的類
- 葉子結點是繼承於主幹，他是乾具體活，實現具體操作的類
- 樹枝是用來存儲葉子結點，同時也是繼承於主幹
拋磚
從這裡我們可以看出不同，我們的查找演算法工程（如上圖）是呈現三層結構，
ST -> SFunction -> XXXST
而組合模式的意思是什麼？
ST -> SFunction -> XXXST; ST->XXXST
所以，通過查找演算法工程的類圖，我們拋磚引玉，引出了真正的組合模式，能夠看出來麽，組合模式的核心思想是在三層基礎上，仍舊保持主幹和葉子結點的關聯關係，這有什麼好處呢？
組合模式解耦了客戶程式與複雜元素內部結構，從而使客戶程式可以像處理簡單元素一樣來處理複雜元素。
換句話說，就是客戶端操作的主幹類，這個主幹類可以註入葉子結點和樹枝，葉子結點就是簡單元素，樹枝因為它本身包含很多葉子結點，因此它是複雜元素。這樣以來，客戶端實際在操作葉子結點和樹枝時，所付出的“辛苦”是相同的。這裡再用演算法工程的類圖來表示就不合適了。
引玉
業界常見的例子是操作系統裡面的文件管理器，我們也來畫一個。
這是組合模式最終的版本的樣子，下麵來解釋一下上面的類圖。
AbstractFile
主幹類，也叫Component，提供給客戶端直接調用的對象，它是目前所有對象的基類，定義了operation方法。
XXXFile
葉子結點，具體文件的具體類型，繼承了AbstractFile類並實現了不同類型文件的具體的operation方法內容，同時它也是Folder對象的一份子，與Folder對象是多對一的關係。
Folder
組合模式的核心對象。首先它也繼承了AbstractFile類，該有的繼承方法和屬性都與XXXFile一樣，然而他的不同之處在於它有一個成員屬性是一個存儲基類的列表，相應地，它還擁有著對這個列表的增刪改查的方法用來堵這個列表進行調整。最後，與XXXFile實現的operation方法的內容不同的是，Folder實現的operation方法是遍歷當前列表並依次調用他們內部具體的operation方法。
組合模式的英文全稱為Composite Pattern，而Folder所代表的對象即上面說的樹枝，英文也被稱為Composite。
組合模式總結
組合模式理解起來非常簡單，也很巧妙，但是要註意在客戶端要調整Composite里的列表時，要直接調用Composite對象的方法，而不是統一隻有一個Component對象暴露在客戶端。這一點確實有損面向對象的封裝性，但是卻避免了將這些列表操作方法放入Component類中，讓葉子結點也去實現這些跟他們毫無關係的方法，並且在運行時一旦有程式調用了葉子結點的這些方法會引發錯亂，相比於此，在客戶端暴露出Composite對象是代價比較小的方式。
- 適用場景
在具有整體和部分的層次結構中，希望通過一種方式忽略整體與部分的差異，客戶端可以一致地對待它們，那就選擇使用組合模式吧。
