從Java類庫看設計模式 (Composite,Strategy,Iterator)

從Java類庫看設計模式 (Composite,Strategy,Iterator)  Java開發

關鍵字：Java類庫看設計模式本文除了還會介紹一個結構型的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模式的一種變體 

雖然將Composite從Component類層次中分離出來，但并沒有損害Composite模式的內涵。這樣做不一定就會比上面的那個要好，各有不同的應用，不過有時候用這樣的方法來處理子樹要容易些，概念上也更為清晰。

原文轉自：http://www.anti-gravitydesign.com