設計模式 -- 適配器模式

適配器模式把一個類的接口變換成客戶端所期待的另外一種接口，從而使本來因接口不匹配而沒法在一塊兒工做的兩個類可以在一塊兒工做。

寫法

定義一個包裝類，用於包裝不兼容接口的對象

• target = 指望得到的能力(某個方法)
• 包裝類 = 適配器Adapter
• 被包裝對象 = Adaptee(擁有能力,但提供的接口不兼容) 和裝飾者模式彷佛有點像,這個後面會提到區別.

類的適配器模式(不建議使用)

組合優先於繼承
基於類的適配器模式經過繼承Adaptee,獲得Adaptee的能力.
咱們能夠經過給適配器Adapter類增長一個實例對象Adaptee,來獲得它的能力.這也就是組合的方式,更加靈活.
注意:若是你想修改Adaptee的接口實現,而不只僅是轉換它的輸入輸出,那其實已經超出了單純適配的含義

對象的適配器模式

這也就是基於組合的適配器模式.
adapter的寫法並不侷限於上面的uml圖,只要實現了轉化,達到了兼容的目的就能夠,來看一個spring的adapter模式

class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {

    @Override
    public boolean supportsAdvice(Advice advice) {
        return (advice instanceof MethodBeforeAdvice);
    }

    @Override
    public MethodInterceptor getInterceptor(Advisor advisor) {
        MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();
        return new MethodBeforeAdviceInterceptor(advice);
    }

}
複製代碼

上面的adapter將Advisor轉化成了對應的攔截器MethodBeforeAdviceInterceptor,使得調用者能夠直接使用攔截器.

使用場景

可能沒有一個架構師會在作系統設計的時候考慮使用適配器模式,每每是系統擴展了,不符合原有設計的時候才考慮經過適配器模式減小代碼修改帶來的風險。
總的來講，適配器模式屬於補償模式，專用來在系統後期擴展、修改時使用。

優勢

• 符合開閉原則
• 靈活性高、低耦合

缺點

一旦一個系統中出現過多的adapter,讀起來會使人十分困惑,我最終到底調用了什麼? 在這種狀況下,可能你須要考慮重構了.

與裝飾者模式的對比

若是你沒看過裝飾者模式,我推薦下面三個連接
開頭

這篇還額外講了實際中常見的半透明的裝飾者模式

這個是git項目‘設計模式’的網站,例子挺有趣的.

裝飾模式和適配器模式都是「包裝模式(Wrapper Pattern)」，它們都是經過封裝其餘對象達到設計的目的的，可是它們的形態有很大區別。 咱們能夠看一個感性的例子:

星巴克咖啡,用奶油,巧克力包裝事後,口味獲得了加強.但它依舊是一個星巴克咖啡.這裏「是」的概念很重要.這是裝飾者模式.

筆記本電腦充電器是三口插頭,家裏只有兩口插座,一個轉換器能夠把三口轉成兩口,這是適配器模式,它強調的是轉換,從不兼容轉化爲兼容.

理想的裝飾模式在對被裝飾對象進行功能加強的同時，要求具體構件角色、裝飾角色的接口與抽象構件角色的接口徹底一致。而適配器模式則否則，通常而言，適配器模式並不要求對源對象的功能進行加強，可是會改變源對象的接口，以便和目標接口相符合。

裝飾模式有透明和半透明兩種，這兩種的區別就在於裝飾角色的接口與抽象構件角色的接口是否徹底一致。透明的裝飾模式也就是理想的裝飾模式，要求具體構件角色、裝飾角色的接口與抽象構件角色的接口徹底一致。相反，若是裝飾角色的接口與抽象構件角色接口不一致，也就是說裝飾角色的接口比抽象構件角色的接口寬的話，裝飾角色實際上已經成了一個適配器角色，這種裝飾模式也是能夠接受的，稱爲「半透明」的裝飾模式，以下圖所示。

在適配器模式裏面，適配器類的接口一般會與目標類的接口重疊，但每每並不徹底相同。換言之，適配器類的接口會比被裝飾的目標類接口寬。

顯然，半透明的裝飾模式實際上就是處於適配器模式與裝飾模式之間的灰色地帶。若是將裝飾模式與適配器模式合併成爲一個「包裝模式」的話，那麼半透明的裝飾模式倒能夠成爲這種合併後的「包裝模式」的表明。