1         Structural Patterns

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

1.1    The Adapter Patten

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

有兩種實(shí)現(xiàn)方式：

1.1.1   The Object Adapter

       通過對象的組合實(shí)現(xiàn)。

1.1.2   The Class Adapter

通過類的繼承來實(shí)現(xiàn)。

1.2    The Composite Patten

用于描述實(shí)際應(yīng)用中經(jīng)常遇到的對象間的樹型層次關(guān)系?；绢悎D：

葉子（Leaf）和Branch（樹枝）有共同的接口TreeNode，這樣，客戶端能以一種統(tǒng)一的方式訪問樹上每個節(jié)點(diǎn)。

       Leaf下不能再有其他子節(jié)點(diǎn)，所以不支持get/add/remove兒子節(jié)點(diǎn)操作。而Branch應(yīng)該有get/add/remove兒子節(jié)點(diǎn)的操作。

       由于Leaf和Branch支持的操作不完全一致，具體實(shí)現(xiàn)可有兩種方式：

1.2.1   Leaf與Branch通過不同接口區(qū)分

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

1.2.2   Leaf與Branch實(shí)現(xiàn)自共同接口

1.2.2.1             共同接口，不同實(shí)現(xiàn)

       Leaf與Branch實(shí)現(xiàn)自共同的接口TreeNode，該接口定義樹結(jié)點(diǎn)支持的操作的合集。Leaf對每一個不支持的操作給定一個空實(shí)現(xiàn)（即操作完成后，對Leaf節(jié)點(diǎn)無任何影響）。這樣對于給定的TreeNode node，客戶端無需區(qū)分是Leaf還是Branch，因?yàn)樗胁僮鞫伎勺饔糜谄渖稀?/span>

1.2.2.2             共同接口，相同實(shí)現(xiàn)

Java Swing中JTree的樹節(jié)點(diǎn)就是采取這種設(shè)計(jì)方式。

1.3    The Decorator Pattern

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

要為每種可能的組合提供一個子類。而Decorator模式卻可以優(yōu)雅的解決該問題。Java I/O類庫的設(shè)計(jì)就大量應(yīng)用了Decorator模式。

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

1.4    The Proxy Pattern

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

       實(shí)際應(yīng)用中，會經(jīng)常用到該模式，因此Java 2已提供java.lang.reflect.Proxy以及java.lang.reflect.InvocationHandler基礎(chǔ)類，使得用戶很容易為任一個類動態(tài)創(chuàng)建代理。

1.5    The Flyweight Pattern

       實(shí)際上是單實(shí)例創(chuàng)建模式的擴(kuò)展。ShareObjectFactory負(fù)責(zé)創(chuàng)建和向外提供有限個ShareObject，這些有限個ShareObject被整個系統(tǒng)共享。ShareObjectFactory自身一般設(shè)計(jì)為單實(shí)例。由于XXXShareObject的實(shí)例要被整個系統(tǒng)共享，所以一般被設(shè)計(jì)為輕量級（Flyweight）的不可變類，而對于依據(jù)運(yùn)行情況可變的外部狀態(tài)，一般作為類的method的參數(shù)傳入。

1.6    The Façade Pattern

       一個復(fù)雜的系統(tǒng)，應(yīng)該對外提供統(tǒng)一，易于使用的Façade（門面）接口/類。客戶端通過Façade與系統(tǒng)交互，而不是直接與該系統(tǒng)的內(nèi)部組件/類通信。這樣，易于設(shè)計(jì)分層的松耦合的各個子系統(tǒng)；且當(dāng)一個子系統(tǒng)有變化時，至多對其Façade做調(diào)整，對系統(tǒng)其它部分沒有影響。

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

1.7    The Bridge Pattern

1.7.1   示例引入

個人認(rèn)為，Bridge Pattern是結(jié)構(gòu)模式中最難理解的一個。

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

覽器的一項(xiàng)重要功能。設(shè)當(dāng)前要支持的圖片格式有gif、bmp、jpg、png、pcx和tiff六種，而瀏覽器要支持的運(yùn)行平臺有Windows、Macinotosh和Unix三種。一種圖片格式的內(nèi)部數(shù)據(jù)結(jié)構(gòu)表示（即圖片二進(jìn)制文件格式）顯然是固定的，與其將在那個平臺顯示沒有任何關(guān)系。而對給定的圖片，如何加載和顯示與平臺相關(guān)，不同的平臺有不同的加載和顯示方式。

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

如此設(shè)計(jì)帶來的問題是：

1．子類過多；

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

3．圖片格式與圖片顯示平臺在代碼級別相互依賴。假設(shè)GIF圖片格式內(nèi)部數(shù)據(jù)結(jié)構(gòu)發(fā)生變化，需要同時修改所有GifInXXX類；假設(shè)對Windows平臺上圖片顯示效果有擴(kuò)展，則需要同時修改所有XXXInWindows類。

因此，需要進(jìn)一步分析，給出新的設(shè)計(jì)方案。面向?qū)ο蠓治龅囊环N重要方法就是“找出可變點(diǎn)并對之封裝（find what varies and encapsulate it）”。對這個系統(tǒng)，有兩個可變點(diǎn)：

可變點(diǎn)1：圖片加載/顯示方式依據(jù)圖片格式可變；

可變點(diǎn)2：圖片加載/顯示方式依據(jù)瀏覽器運(yùn)行平臺可變。

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

這樣設(shè)計(jì)，好處顯而易見：

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

l         當(dāng)新增一種圖片格式時，只需增加一個XXXImage類；現(xiàn)有某種圖片格式發(fā)生變化時，只需修改對應(yīng)的一個XXXImage類；

l         當(dāng)新增一種支持平臺時，只需增加一個XXXHandler類；對現(xiàn)有某種平臺圖片顯示效果有新要求時，只需修改對應(yīng)的一個XXXHandler類。

事實(shí)上，如此設(shè)計(jì)應(yīng)用的就是所謂Bridge Pattern。從類圖上來看，AbstractImage/PlatformPresentHandler就像是AXXXImage系列和XXXHandler系列之間的橋梁。

1.7.2   提煉

1．基本類圖

2．適用場合