1.概述
這個設計模式有點像數據結構中的樹。分別有葉子節點可非葉子節點，葉子節點沒有子節點，而非葉子節點有子節點，非葉子節點又可以是別的非葉子節點的子節點。
2.問題
有一個對象，他是由其他的部件組成，這些部件又由很多其他的零件組成，形成了一個部分-整體的結構，這是一種類似於樹的結構，整體又可以去構成其他整體，就像非葉子節點。我們可以把這些由很多其他零件組成的部件定義爲容器，零件定義爲單個的對象，但是這樣用戶得區分容器和部件的用法。但是實際上，這些部件在客戶看來是一樣的，這些東西如果區別使用，那麼代碼就將變得很複雜，所以我們想一種辦法，使得用戶不必區分部件和對象。
3.問題解決
設計模式中的composite模式，就是用來解決部分和整體使用不一致矛盾的。比如在一個樹，不區分葉子節點和非葉子節點了。大家經常使用的文件目錄就是用這種方式構造的。葉子節點就是我們的每一個文件，而非葉子節點就是我們的文件夾。
4.composi模式的角色
component 接口定義了所有節點的方法，並默認了葉子節點沒有的方法爲空方法（即管理子節點的方法）。
composite 這個定義了管理子節點的方法。
leaf 節點，這就是葉子節點。
說明：對於很多訪問子節點的方法，如何防止沒注意被leaf調用呢，那就是定義一個getComposite方法，默認爲空，而composite對其進行實現。
5。適用性：
1）如果你想表示整體-部分結構
2）如果你想讓client忽略整體和部分的使用區別。
這就是composite的結構。
使用的好處
1）定義了包含基本對象和組合對象的類層次結構 基本對象可以被組合成更復雜的組合對象，而這個組合對象又可以被組合，這樣不斷的遞歸下去。客戶代碼中，任何用到 基本對象的地方都可以使用組合對象。
2) 簡化客戶代碼 客戶可以一致地使用組合結構和單個對象。通常用戶不知道 (也不關心)處理的是一個葉節點還是一個組合組件。這就簡化了客戶代碼 , 因爲在定義組合的那些類中不需要寫一些充斥着選擇語句的函數。
3) 使得更容易增加新類型的組件 新定義的Composite或Leaf子類自動地與已有的結構和客戶代碼一起工作，客戶程序不需因新的Component類而改變。4) 使你的設計變得更加一般化 容易增加新組件也會產生一些問題，那就是很難限制組合中的組件。有時你希望一個組合只能有某些特定的組件。使用Composite時，你不能依賴類型系統施加這些約束，而必須在運行時刻進行檢查。
