1         Structural Patterns

描述如何通過類的繼承和對象間的組合來解決應用開發中常見問題。

1.1    The Adapter Patten

把一個已有類的某個接口變換成客戶端所期待的另一個接口，從而使原本因接口不匹配而無法在一起工作的兩個類能在一起工作。

有兩種實現方式：

1.1.1   The Object Adapter

       通過對象的組合實現。

1.1.2   The Class Adapter

 

通過類的繼承來實現。

1.2    The Composite Patten

用于描述實際應用中經常遇到的對象間的樹型層次關系。基本類圖：

 

葉子（Leaf）和Branch（樹枝）有共同的接口TreeNode，這樣，客戶端能以一種統一的方式訪問樹上每個節點。

       Leaf下不能再有其他子節點，所以不支持get/add/remove兒子節點操作。而Branch應該有get/add/remove兒子節點的操作。

       由于Leaf和Branch支持的操作不完全一致，具體實現可有兩種方式：

1.2.1   Leaf與Branch通過不同接口區分

 

       給定一個TreeNode node，當需要時，通過 “if (node instancof IBranch)”或“if (node instanceof ILeaf)”來判斷其是Leaf還是Branch，從而獲取其所支持的操作。

1.2.2   Leaf與Branch實現自共同接口

1.2.2.1             共同接口，不同實現

 

       Leaf與Branch實現自共同的接口TreeNode，該接口定義樹結點支持的操作的合集。Leaf對每一個不支持的操作給定一個空實現（即操作完成后，對Leaf節點無任何影響）。這樣對于給定的TreeNode node，客戶端無需區分是Leaf還是Branch，因為所有操作都可作用于其上。

1.2.2.2             共同接口，相同實現

在共同接口TreeNode中增加“boolean isLeaf()”方法，用于區分節點是Leaf還是Branch。

 

Java Swing中JTree的樹節點就是采取這種設計方式。

1.3    The Decorator Pattern

對于需要通過基本功能的排列組合來產生大功能的應用場景，如果采用繼承方式，勢必

要為每種可能的組合提供一個子類。而Decorator模式卻可以優雅的解決該問題。Java I/O類庫的設計就大量應用了Decorator模式。

 

       用戶可以按需將多個Decorator的排列組合作用于ConcreteComponent之上，從而為基本function()增加新特性。

1.4    The Proxy Pattern

顧名思義，很好理解。通過Proxy，控制客戶端直接創建和訪問核心RealSubject。

 

       實際應用中，會經常用到該模式，因此Java 2已提供java.lang.reflect.Proxy以及java.lang.reflect.InvocationHandler基礎類，使得用戶很容易為任一個類動態創建代理。

1.5    The Flyweight Pattern

 

       實際上是單實例創建模式的擴展。ShareObjectFactory負責創建和向外提供有限個ShareObject，這些有限個ShareObject被整個系統共享。ShareObjectFactory自身一般設計為單實例。由于XXXShareObject的實例要被整個系統共享，所以一般被設計為輕量級（Flyweight）的不可變類，而對于依據運行情況可變的外部狀態，一般作為類的method的參數傳入。

1.6    The Façade Pattern

 

       一個復雜的系統，應該對外提供統一，易于使用的Façade（門面）接口/類。客戶端通過Façade與系統交互，而不是直接與該系統的內部組件/類通信。這樣，易于設計分層的松耦合的各個子系統；且當一個子系統有變化時，至多對其Façade做調整，對系統其它部分沒有影響。

       舉個例子，Hibernate作為一個ORM實現，本身是一個復雜的系統。但通過其對外提供的Configure/SessionFactory/Session/Query等接口或類，用戶很方便使用，而這些接口或類就是Hibernate的Façade。

1.7    The Bridge Pattern

1.7.1   示例引入

個人認為，Bridge Pattern是結構模式中最難理解的一個。

好的示例勝于千言萬語。假設要設計一個跨平臺瀏覽器，而各種格式圖片的顯示是該瀏

覽器的一項重要功能。設當前要支持的圖片格式有gif、bmp、jpg、png、pcx和tiff六種，而瀏覽器要支持的運行平臺有Windows、Macinotosh和Unix三種。一種圖片格式的內部數據結構表示（即圖片二進制文件格式）顯然是固定的，與其將在那個平臺顯示沒有任何關系。而對給定的圖片，如何加載和顯示與平臺相關，不同的平臺有不同的加載和顯示方式。

需求明了后，如何設計？一種直觀的設計是定義一個接口Image，然后為每一種圖片格式與平臺的組合提供一個實現類，共6×3＝18個。如下圖所示：

 

如此設計帶來的問題是：

1．子類過多；

2．子類可能有大量重復代碼。例如，每個GifInXXX類的load()方法中都有對*.gif文件進行解析的代碼片斷，而這些代碼都是相同的。

3．圖片格式與圖片顯示平臺在代碼級別相互依賴。假設GIF圖片格式內部數據結構發生變化，需要同時修改所有GifInXXX類；假設對Windows平臺上圖片顯示效果有擴展，則需要同時修改所有XXXInWindows類。

因此，需要進一步分析，給出新的設計方案。面向對象分析的一種重要方法就是“找出可變點并對之封裝（find what varies and encapsulate it）”。對這個系統，有兩個可變點：

可變點1：圖片加載/顯示方式依據圖片格式可變；

可變點2：圖片加載/顯示方式依據瀏覽器運行平臺可變。

且這兩個可變點應能夠獨立發生變化，無依賴。對可變點2抽象為一個接口PlatformPresentHandler，不同的平臺給出不同的實現。不同格式的圖片類都有一個對PlatformPresentHandler的引用handlder，用于動態指定圖片的顯示平臺，同時封裝僅與各自格式相關的加載/顯示代碼。完整的圖片加載/顯示功能由格式相關代碼和handler相關method組合完成。最后將所有不同格式圖片類進一步抽象為AbstractImage，以便瀏覽器能以一種統一方式處理不同格式圖片。如下圖所示：

 

這樣設計，好處顯而易見：

l         子類數目減少，只需6+3=9個；

l         當新增一種圖片格式時，只需增加一個XXXImage類；現有某種圖片格式發生變化時，只需修改對應的一個XXXImage類；

l         當新增一種支持平臺時，只需增加一個XXXHandler類；對現有某種平臺圖片顯示效果有新要求時，只需修改對應的一個XXXHandler類。

事實上，如此設計應用的就是所謂Bridge Pattern。從類圖上來看，AbstractImage/PlatformPresentHandler就像是AXXXImage系列和XXXHandler系列之間的橋梁。

1.7.2   提煉

1．基本類圖

 

2．適用場合

       一個構件功能實現依賴多個可變點，而這些可變點又不相互依賴，可以獨立變化。