設計模式之接口型模式

接口型模式包括了：適配器模式、外觀模式、組合模式和橋接模式。

接口型模式主要解決什麼問題？

       類Client的實例instanceClient但願使用另外一個對象instanceX提供的服務service，但在設計時，咱們並不能肯定對象instanceX究竟屬於哪一個類。

解決的辦法：

       將對象instanceX提供的服務service抽象爲一個接口ServiceProvider，而後讓對象instanceClient經過持有接口ServiceProvider的實例來使用服務service。

一、適配器模式（Adapter）

       將一個類的接口轉換成客戶系統的另一個接口。Adapter模式使得本來因爲接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做。主要經過繼承解決在軟件系統中，經常要將一些"現存的對象"放到新的環境中，而新環境要求的接口是現對象不能知足的。必須注意的是適配器不是在詳細設計時添加的，而是解決正在服役的項目的問題。

       優勢：一、可讓任何兩個沒有關聯的類一塊兒運行。 二、提升了類的複用。 三、增長了類的透明度。 四、靈活性好。

       缺點：過多地使用適配器，會讓系統很是零亂，不易總體進行把握。好比，明明看到調用的是 A 接口，其實內部被適配成了 B 接口的實現，一個系統若是太多出現這種狀況，無異於一場災難。所以若是不是頗有必要，能夠不使用適配器，而是直接對系統進行重構。

       使用場景：有動機地修改一個正常運行的系統的接口，這時應該考慮使用適配器模式。

       舉例說明一下，好比說如今有一個音樂播放器，它只能支持音樂文件mp3的播放，而不能支持其它音樂文件的播放，固然視頻文件是不支持播放的；可是音樂文件卻有不少種，好比說mp三、mp四、wav等，針對不一樣的音樂文件，咱們都應該能播放它，這纔是一個合格的音樂播放器。

       那麼如何擴展這個簡易的音樂播放器呢：

       第一步：原本有一個播放器接口（意思就是隻要是個播放器就應該具備的功能），裏面就只有播放一個功能

       

       第二步：建立一個我要開發的更高級的播放器接口，能夠播放wav和mp4格式的播放功能

       

       第三步：我要播放wav、mp4格式，那麼我就要作兩個播放器以至能夠播放這兩種格式的音樂文件的播放器

       

       

       第四步：既然有了兩個格式的播放器，那麼我就要作一個適配器，以致於每種格式的音樂文件進來，都能自動匹配去播放

       

       第五步：對本來的播放器擴展功能（使用適配器），擴展能夠播放mp4和wav音樂

       

       最後運行驗證一下高級那麼一丟丟的播放器：

       

       輸出結果：

       

 二、外觀模式（Facade）

       爲子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。主要是爲了下降訪問複雜系統的內部子系統時的複雜度，簡化客戶端與之的接口。

      

        原本兩個用戶，調用的不一樣的接口，若是再來幾個客戶，又是調用不一樣的接口，會形成整個調用體系很是混亂，因此爲了使客戶端不與系統耦合，而定義了外觀類與系統耦合。

        

       優勢： 一、減小系統相互依賴。 二、提升靈活性。 三、提升了安全性。 

       缺點：不符合開閉原則，若是要改東西很麻煩，繼承重寫都不合適。

      使用場景：一、爲複雜的模塊或子系統提供外界訪問的模塊。 二、子系統相對獨立。 三、預防低水平人員帶來的風險。

       舉個例子就是，超市給人提供的服務。若是說，一個顧客想要買雞蛋、葡萄、鞋子，若是他不去超市，那他就要先找到賣雞蛋的店鋪其買雞蛋，接着去買水果的點買葡萄，去生活用品店買鞋子，多麻煩。而你只要去超市，就能夠一次性買到這三種東西。甚至，你到超市，連去拿雞蛋、葡萄、鞋子都懶得去，那就叫超市的服務員也一樣是這個意思（我很懷疑如今超市有沒有這樣的服務，哈哈哈）。

       第一步：建立一個超市接口，定義這個超市賣東西的

       

       第二步：實現這個超市的接口，就是說，超市裏具體賣的什麼東西

       

       

       

       第三步：建立一個超市的超級好的服務員

       

       最後：告訴服務員你要買的東西，讓服務員去拿（哈哈哈）

       

       輸出結果：

      

三、組合模式（Composite）

      將對象組合成樹形結構以表示「部分-總體」的層次結構。Composite使得客戶對單個對象和複合對象的使用具備一致性。它在咱們樹型結構的問題中，模糊了簡單元素和複雜元素的概念，客戶程序能夠向處理簡單元素同樣來處理複雜元素，從而使得客戶程序與複雜元素的內部結構解耦。    

      優勢： 一、高層模塊調用簡單。 二、節點自由增長。

      缺點：由於葉結點和枝結點調用同一個接口，全部葉結點會實現一些沒有意義的方法功能。

      使用場景：部分、總體場景，如樹形菜單，文件、文件夾的管理。

      舉個簡單的栗子，當咱們買東西的時候打成一個包，就是隻要總體，但所買到的東西有單個的，也有已經打包（組合）了的，這個時候咱們又要把單個的與已經打包的打成一個大包（注意，這裏不是說要把以前打好的包再添加一個，而是兩個一塊兒打成一個大包，匯成一個總體）。

      第一步：建立一個接口

      

      第二步：單個對象與組合對象實現這個接口

      

      

      最後：將組合對象和單個對象一塊兒打包

      

      輸出：

      

四、橋接模式（BridgePattern）

       將抽象部分與它的實現部分分離，使它們均可以獨立地變化。主要是由於在有多種可能會變化的狀況下，用繼承會形成類爆炸問題，擴展起來不靈活。   

       優勢： 一、抽象和實現的分離。 二、優秀的擴展能力。 三、實現細節對客戶透明。

       缺點：橋接模式的引入會增長系統的理解與設計難度，因爲聚合關聯關係創建在抽象層，要求開發者針對抽象進行設計與編程。

       使用場景： 一、若是一個系統須要在構件的抽象化角色和具體化角色之間增長更多的靈活性，避免在兩個層次之間創建靜態的繼承聯繫，經過橋接模式可使它們在抽象層創建一個關聯關係。 二、對於那些不但願使用繼承或由於多層次繼承致使系統類的個數急劇增長的系統，橋接模式尤其適用。 三、一個類存在兩個獨立變化的維度，且這兩個維度都須要進行擴展。 

       舉個栗子，好比說畫一個圓，這個圓有兩個維度，一個是這個圓的大小，座標；還有一個是這個圓的顏色。那麼就能夠用橋接的模式來實現

       第一步：建立一個橋接實現接口

       

       第二步：建立實現這個接口的實體類

       

       

       第三步：使用橋接接口建立圖形的抽象類

       

       第四步：建立實現抽象類

       

       最後：畫出不一樣顏色不一樣大小的圓

       

       輸出：

        

       橋接模式與適配器模式有點類似：

              共同點：橋接和適配器都是讓兩個東西配合工做。

             不一樣點：出發點不一樣。

                   適配器：改變已有的兩個接口，讓他們相容。

                   橋接模式：分離抽象化和實現，使二者的接口能夠不一樣，目的是分離。

       因此說，若是你拿到兩個已有模塊，想讓他們同時工做，那麼你使用的適配器。若是你還什麼都沒有，可是想分開實現，那麼橋接是一個選擇。橋接是先有橋，纔有兩端的東西，適配是先有兩邊的東西，纔有適配器，橋接是在橋好了以後，兩邊的東西還能夠變化。例如遊戲手柄，就象個橋，它把你的任何操做轉化成指令。