設計模式之迭代器與組合模式（三）

如今咱們已經能愉快地看着一頁一頁羅列出來的菜單進行點菜了。如今又有的小夥伴但願可以加上一份餐後甜點的「子菜單」。怎麼辦呢？咱們不單單要支持多個菜單，甚至還要支持菜單中的菜單。

若是咱們能讓甜點菜單變成餐廳菜單集合的一個元素，那該有多好。可是根據如今的實現，根本作不到呀。咱們想要的是這樣的:

咱們須要什麼

如今咱們遇到的現實問題是，咱們的系統已經達到了一個複雜的級別，若是如今不從新設計，就沒法容納將來增長的菜單或子菜單等需求。

因此，在咱們的新設計中，真正須要些什麼呢？

• 咱們須要某種樹形結構，能夠容納菜單、子菜單和菜單項
• 咱們須要肯定可以在每一個菜單的各個項之間遊走，並且至少要像如今用迭代器同樣方便
• 咱們也須要可以更有彈性地在菜單項之間遊走。比方說，可能只須要遍歷甜點菜單，或者能夠遍歷餐廳的整個菜單（包括甜點菜單在內）。

定義組合模式

沒錯，咱們要介紹另外一個模式解決這個難題。咱們並無放棄迭代器--它仍然是咱們解決方案中的一部分--然而，管理菜單的問題已經到了一個迭代器沒法解決的新維度。因此，咱們將倒退幾步，改用組合模式來實現。

組合模式：容許你將對象組合成樹形結構來表現「總體/部分」層次結構。組合能讓客戶以一致的方式處理個別對象以及對象組合。

讓咱們以菜單爲例思考這一切：這個模式可以建立一個樹形結構，在同一個結構中處理嵌套菜單和菜單項組。經過將菜單和項放在相同的結構中，咱們建立了一個「總體/部分」層次結構，即由菜單和菜單項組成的對象樹。可是能夠將它視爲一個總體，像是一個豐富的大菜單。

一旦有了豐富的大彩蛋，咱們就可使用這個模式來「統一處理個別對象和組合對象」。這意味着什麼？它意味着，若是咱們有了一個樹形結構的菜單、子菜單和可能還帶有菜單項的子菜單，那麼任何一個菜單都是一種「組合」。

由於它既能夠包含其餘菜單，也能夠包含菜單項。個別對象只是菜單項--並未持有其餘對象。就像你將看到，使用一個遵守組合模式的設計，讓咱們可以寫出簡單的代碼，就可以對整個菜單結構應用相同的操做。

結合圖來描述以下：

組合模式的類圖以下：

瞭解完組合模式的種種，在下次的推文中，咱們將用於實際操做。咱們利用組合模式設計菜單，而且使用菜單，以此來鞏固加深。敬請期待吧。

愛生活，愛學習，愛感悟，愛挨踢