描述如何通過類的繼承和對象間的組合來解決應(yīng)用開發(fā)中常見問題。
把一個已有類的某個接口變換成客戶端所期待的另一個接口，從而使原本因接口不匹配而無法在一起工作的兩個類能在一起工作。
有兩種實現(xiàn)方式：
通過對象的組合實現(xiàn)。
通過類的繼承來實現(xiàn)。
用于描述實際應(yīng)用中經(jīng)常遇到的對象間的樹型層次關(guān)系?；绢悎D：
葉子（Leaf）和Branch（樹枝）有共同的接口TreeNode，這樣，客戶端能以一種統(tǒng)一的方式訪問樹上每個節(jié)點。
Leaf下不能再有其他子節(jié)點，所以不支持get/add/remove兒子節(jié)點操作。而Branch應(yīng)該有get/add/remove兒子節(jié)點的操作。
由于Leaf和Branch支持的操作不完全一致，具體實現(xiàn)可有兩種方式：
給定一個TreeNode node，當(dāng)需要時，通過 “if (node instancof IBranch)”或“if (node instanceof ILeaf)”來判斷其是Leaf還是Branch，從而獲取其所支持的操作。
Leaf與Branch實現(xiàn)自共同的接口TreeNode，該接口定義樹結(jié)點支持的操作的合集。Leaf對每一個不支持的操作給定一個空實現(xiàn)（即操作完成后，對Leaf節(jié)點無任何影響）。這樣對于給定的TreeNode node，客戶端無需區(qū)分是Leaf還是Branch，因為所有操作都可作用于其上。
在共同接口TreeNode中增加“boolean isLeaf()”方法，用于區(qū)分節(jié)點是Leaf還是Branch。
Java Swing中JTree的樹節(jié)點就是采取這種設(shè)計方式。
對于需要通過基本功能的排列組合來產(chǎn)生大功能的應(yīng)用場景，如果采用繼承方式，勢必
要為每種可能的組合提供一個子類。而Decorator模式卻可以優(yōu)雅的解決該問題。Java I/O類庫的設(shè)計就大量應(yīng)用了Decorator模式。
用戶可以按需將多個Decorator的排列組合作用于ConcreteComponent之上，從而為基本function()增加新特性。
顧名思義，很好理解。通過Proxy，控制客戶端直接創(chuàng)建和訪問核心RealSubject。
實際應(yīng)用中，會經(jīng)常用到該模式，因此Java 2已提供java.lang.reflect.Proxy以及java.lang.reflect.InvocationHandler基礎(chǔ)類，使得用戶很容易為任一個類動態(tài)創(chuàng)建代理。
實際上是單實例創(chuàng)建模式的擴展。ShareObjectFactory負責(zé)創(chuàng)建和向外提供有限個ShareObject，這些有限個ShareObject被整個系統(tǒng)共享。ShareObjectFactory自身一般設(shè)計為單實例。由于XXXShareObject的實例要被整個系統(tǒng)共享，所以一般被設(shè)計為輕量級（Flyweight）的不可變類，而對于依據(jù)運行情況可變的外部狀態(tài)，一般作為類的method的參數(shù)傳入。
一個復(fù)雜的系統(tǒng)，應(yīng)該對外提供統(tǒng)一，易于使用的Façade（門面）接口/類?？蛻舳送ㄟ^Façade與系統(tǒng)交互，而不是直接與該系統(tǒng)的內(nèi)部組件/類通信。這樣，易于設(shè)計分層的松耦合的各個子系統(tǒng)；且當(dāng)一個子系統(tǒng)有變化時，至多對其Façade做調(diào)整，對系統(tǒng)其它部分沒有影響。
舉個例子，Hibernate作為一個ORM實現(xiàn)，本身是一個復(fù)雜的系統(tǒng)。但通過其對外提供的Configure/SessionFactory/Session/Query等接口或類，用戶很方便使用，而這些接口或類就是Hibernate的Façade。
個人認為，Bridge Pattern是結(jié)構(gòu)模式中最難理解的一個。
好的示例勝于千言萬語。假設(shè)要設(shè)計一個跨平臺瀏覽器，而各種格式圖片的顯示是該瀏
覽器的一項重要功能。設(shè)當(dāng)前要支持的圖片格式有gif、bmp、jpg、png、pcx和tiff六種，而瀏覽器要支持的運行平臺有Windows、Macinotosh和Unix三種。一種圖片格式的內(nèi)部數(shù)據(jù)結(jié)構(gòu)表示（即圖片二進制文件格式）顯然是固定的，與其將在那個平臺顯示沒有任何關(guān)系。而對給定的圖片，如何加載和顯示與平臺相關(guān)，不同的平臺有不同的加載和顯示方式。
需求明了后，如何設(shè)計？一種直觀的設(shè)計是定義一個接口Image，然后為每一種圖片格式與平臺的組合提供一個實現(xiàn)類，共6×3＝18個。如下圖所示：
如此設(shè)計帶來的問題是：
1．子類過多；
2．子類可能有大量重復(fù)代碼。例如，每個GifInXXX類的load()方法中都有對*.gif文件進行解析的代碼片斷，而這些代碼都是相同的。
3．圖片格式與圖片顯示平臺在代碼級別相互依賴。假設(shè)GIF圖片格式內(nèi)部數(shù)據(jù)結(jié)構(gòu)發(fā)生變化，需要同時修改所有GifInXXX類；假設(shè)對Windows平臺上圖片顯示效果有擴展，則需要同時修改所有XXXInWindows類。
因此，需要進一步分析，給出新的設(shè)計方案。面向?qū)ο蠓治龅囊环N重要方法就是“找出可變點并對之封裝（find what varies and encapsulate it）”。對這個系統(tǒng)，有兩個可變點：
可變點1：圖片加載/顯示方式依據(jù)圖片格式可變；
可變點2：圖片加載/顯示方式依據(jù)瀏覽器運行平臺可變。
且這兩個可變點應(yīng)能夠獨立發(fā)生變化，無依賴。對可變點2抽象為一個接口PlatformPresentHandler，不同的平臺給出不同的實現(xiàn)。不同格式的圖片類都有一個對PlatformPresentHandler的引用handlder，用于動態(tài)指定圖片的顯示平臺，同時封裝僅與各自格式相關(guān)的加載/顯示代碼。完整的圖片加載/顯示功能由格式相關(guān)代碼和handler相關(guān)method組合完成。最后將所有不同格式圖片類進一步抽象為AbstractImage，以便瀏覽器能以一種統(tǒng)一方式處理不同格式圖片。如下圖所示：
這樣設(shè)計，好處顯而易見：
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è)計應(yīng)用的就是所謂Bridge Pattern。從類圖上來看，AbstractImage/PlatformPresentHandler就像是AXXXImage系列和XXXHandler系列之間的橋梁。
1．基本類圖
2．適用場合
一個構(gòu)件功能實現(xiàn)依賴多個可變點，而這些可變點又不相互依賴，可以獨立變化。
