原創作品，可以轉載，但是請標注出處地址：http://www.cnblogs.com/V1haoge/p/6508967.html
之前認真學習了Java設計模式中的四大接口型模式，分別為：適配器模式（Adapter）、外觀模式（Facade）、合成模式（Composite）、橋接模式（Bridge）。
1、在此處再溫習一下四種設計模式：
（1）適配器模式：
我們能夠訪問的類中不存在我們要訪問的內容時，就可以使用這個適配器模式，當然就類而言，其實不存在什么不能被訪問，這里的不能訪問都是人為的制約，規則的限制。
最為常見的就是在常規項目中使用的MVC分層模式，尤其在SpringMVC中體現的淋漓盡致：我們的請求來到SpringMVC的核心Servlet（DispatcherServlet）之后，由其進行請求分發，找尋合適的控制器（Controller），一般控制器是不會進行任何的業務處理的，它的作用就是用來接收請求與返回響應，而具體的請求與響應的處理則是在業務層（Service層）實現。
這樣請求的目的很明確，就是要進行業務處理，而接收請求的控制器被人為（規則）限制不允許內部出現任何業務代碼，怎么辦？將其當做一個適配器來處理，使用組合的方式來控制器所在類中引用業務類（接口指向實現類），然后在控制器方法中調用能夠完成請求目的的一個或者若干業務層類中的方法來進行業務處理，這正是適配器模式的一種典型應用。
請參考《Java設計模式之《適配器模式》及應用場景》一文
（2）外觀模式：
外觀也就是臉面、門臉，並不是說我們一定要使用外觀，而是使用外觀可以有諸多好處，它能夠屏蔽系統復雜性，而且如果對系統功能的實現進行優化或更改，只需要對外觀類進行簡單的更新即可，而不會影響到使用這個系統的其他系統，這是外觀類最重要的功能。
在這里我突然想到，上面舉的例子中，控制器調用業務層實現類來完成具體的業務處理，從某種角度來看，同樣也是外觀模式的一種應用：控制器類針對整個網站業務系統而言何嘗不是一個外觀類的存在，外部請求來到系統后台，直面的正是這些控制器類，而不是復雜的業務處理類，在控制器中通過調用業務類方法的方式來為外部請求提供服務，這樣整個復雜的后台業務系統被接口屏蔽，請求者不必關心自己要調用哪個業務類來實現自己的請求，而是有特定的控制器來完成這個內部調用。當我們對業務實現方法進行修正或更新時，只需要在控制器中稍作修改即可，整個請求毫無影響，對它而言未發生任何改變。
只是突然想到一點：我記得在外觀模式中有這樣的描述，外觀類對系統並不是真正的屏蔽，其他系統任然可以通過直接調用系統內部的方法來完成功能，只是較為復雜罷了，這在SpringMVC中好像無法達成，因為SpringMVC被設計成為接口匹配方式來尋找控制器，也就是說請求來臨只能找控制器，是無法直接調用業務實現類的，也許通過一些復雜的方式可能達到。
請參考《Java設計模式之《外觀模式》及應用場景》一文
（3）合成模式：
有別於之前和之后要談及到的模式，我認為合成模式較為狹隘，是指應用范圍較為狹隘，好像主要針對的就是樹形結構而言，如文件目錄、多級目錄結構等。
使用合成模式的目的並不是組合（即將下一級包含在上一級中），而在於一視同仁這一點。
何為一視同仁？簡單的說就是將樹形結構的兩種形式一概而論，將目錄結構的文件與目錄一概而論，而不是分而論之。
如果將兩者一視同仁，那么就能將二者抽象為一個概念（通常應該是用抽象類來表述），然后我們再針對二者分開進行抽象的繼承實現，具體的區分二者，這樣做，好似比原本就分而論之的結構要復雜，其實不然，我們使用抽象后，二者被概括為一個概念，這樣我們在使用的時候，就可以使用同一個接口來進行實現（Java中的多態：抽象類指向實現類），具體的實現不必在代碼中指定，而是自動根據情況來完成。這樣不必再針對二者分開進行顯式調用，簡化了代碼。
請參考《Java設計模式之《橋接模式》及應用場景》一文
（4）橋接模式：
以前諸多文章都未能在博客園首頁留住，但這篇文章《Java設計模式之《橋接模式》及應用場景》盡然入了編輯的眼，進而被達人科技發布到了《今日頭條》上，說明這篇文章還是不錯的。
說道橋接模式，又稱橋梁模式，望文生義，就是一座橋。這是一座接口橋。
查閱諸多文獻，說道橋接模式就是將抽象與實現解耦，說實在話，不懂！因為這句話本身就抽象至極，談何理解！
其實此處的抽象指的是調用方的抽象類實現，實現指的是被調用方的接口實現，這里談及到兩個實現，正是我們常見的實現：就是通過繼承的方式來實現抽象類，通過實現的方式來實現接口，無外乎如此。
再談談解耦，這里的解耦也很好理解，就是解除直接耦合，什么樣式直接耦合呢，很簡單，通過繼承類的方式實現的功能就是直接耦合，這樣的耦合導致修改和擴展將會極為麻煩，這也正是解耦的目的所在。
再談談如何解耦，這里涉及到的雙方就是調用者與被調用者，如果通過繼承的方式來進行雖然符合Java繼承規則，但耦合性太大，不易雙方擴展，這樣在二者之間架設一道橋梁，將二者的那種耦合隔開，通過中間橋來進行連接，這樣一來，雙方的擴展不再對對方產生任何影響，可以任意發展。
那么如何來架設這道橋梁呢？
很簡單，使用接口與抽象類這兩個神器，我們為被調用者創建一個接口，而這個接口就是那座橋，其實我們將橋與被調用者綁定在一起了，而針對調用者，我們創建一個抽象類（為何此處是抽象類，而不是接口呢？因為我們要在這個抽象類內部引用橋接口，而接口中一般是沒有屬性的<只有靜態常量>），故使用抽象類），在其中引用橋接口，並創建合適的方法，用於被繼承類實現來進行擴展。
如此一來，目的達成，不明白的，請看《Java設計模式之《橋接模式》及應用場景》一文。
2、接口類型
上述的四種設計模式均涉及到了接口，此處的接口並不是Interface這個意思，而是一種“對外”或“被調用”的意思，還有一層屏蔽的意思。
接口類型多是使用接口來屏蔽具體的實現，為調用者提供一個友好的界面（接觸口）。
（理解尚淺，待補充）
Java設計模式之《組合模式》及應用場景