從Java類庫看設計模式（4）

在上一部分中，介紹了兩個結構型的模式：Bridge和Decorator。這一部分的內容，將會 接著上面的講解，繼續我們的設計模式之旅。

這一部分，除了還會介紹一個結構型的Composite模式之外，還會有兩個行為模式登場。 實際上在前面的內容中，我們已經接觸到行為模式了：Observer和Command就是兩個典型的行 為模式。行為模式更多的注重於演算法和對象建間職責的分配，也就是說，它會更多的關注於 這個模式系統之類的各對象協作間的語義，以及在對象間進行通訊的流量控制。

Composite模式

毫無疑問的，AWT中的Component-Container體系就是一個很好的Composite模式的例子。 Container繼承於Component，而Container中有可以包含有多個Component，因為Container實 際上也是Component，因而Container也可以包含Container。這樣通過Component-Container 結構的對象組合，形成一個樹狀的階層。這也就是Composite模式所要做的。

Composite模式是為了簡化編程而提出的，一般的在編程的時候，如果嚴格的區分 Component和Container的話，有時候會帶來許多不便，而且這些往往是沒有必要的。比如， 我要在一個Container中放置一個Component，我並不需要知道這個Component到底是一個 Container，或者就是一個一般的Component，在父級容器中所要做的，只是記錄一個 Component的引用，在需要的時候調用Component的繪製方法來顯示這個Component。當這個 Component確實是一個Container的時候，它可以通過Container重載後的繪製方法，完成對這 個容器的顯示，並把繪製訊息傳遞給到它的子物件去。也就是說，對一個父級容器而言，它 並不不關心，其子物件到底是一個Component，還是一個Container。它需要將Component和 Container統一對待。

圖十一：Composite模式的類圖

Composite模式比較簡單，實現起來也不複雜，但是有一定的局限性。比如，在處理樹的 時候，我們往往需要處理三類對象：子樹，頁節點和非頁節點。而在Composite模式中對於子 樹和非分葉節點的區分並不明顯，而是把他們合成為一個Composite對象了。而且在GOF給出的 Composite的模式中，對於添加，刪除子節點等屬於Composite對象的的方法，是放在了 Component對象中的，這雖然在實現的時候可以區分開來，但容易造成一些概念上的誤解。

由上所敘，我們可以提出一個改進了的Composite模式，引入子樹對象，從而將子樹和非 分葉節點分開，如下圖所示：

圖十二：Composite模式的一種變體