定義

適配器模式把一個(gè)類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無(wú)法在一起工作的兩個(gè)類能夠在一起工作。

適配器模式的用途

用電器做例子，筆記本電腦的插頭一般都是三相的，即除了陽(yáng)極、陰極之外，還有一個(gè)地極。而有些地方的電源插座卻只有兩極，沒(méi)有地極。電源插座與筆記本電腦的電源插頭不匹配使得筆記本電腦無(wú)法使用。這時(shí)候一個(gè)三相到兩相的轉(zhuǎn)換器（適配器）就能解決此問(wèn)題，而這正像是本模式所做的事情。

適配器模式的結(jié)構(gòu)

適配器模式有類的適配器模式和對(duì)象的適配器模式兩種不同的形式。

類的適配器模式

類的適配器模式吧適配的類的API轉(zhuǎn)換成為目標(biāo)類的API。

類的適配器模式

從上圖可以看出，Adaptee類并沒(méi)有sampleOperation2()方法，而客戶端則期待這個(gè)方法。為了使客戶端能夠使用Adaptee類，提供一個(gè)中間環(huán)節(jié)，即類Adapter，把Adaptee類的API同Target接口的API銜接起來(lái)。Adapter與Adaptee是繼承關(guān)系，這決定了這個(gè)適配器模式是類的適配器模式。

模式中涉及到的角色有：

• 目標(biāo)(Target)角色：這就是所期待得到的接口。注意：由于這里討論的是類適配器模式，因此目標(biāo)不可以是類。
• 源(Adaptee)角色：現(xiàn)在需要適配的接口。
• 適配器(Adapter)角色：適配器類是本模塊的核心。適配器把源接口轉(zhuǎn)換成目標(biāo)接口。顯然，這一角色不可以是接口，而必須是具體類。

示例代碼

public interface Target {
    /**
     * 這是源類Adaptee中也有的方法
     */
    public void sampleOperation1();
    /**
     * 這是源類Adaptee中沒(méi)有的方法
     */
    public void sampleOperation2();
}

上面給出的是目標(biāo)角色的接口代碼，這個(gè)角色是以一個(gè)Java接口的形式實(shí)現(xiàn)的?？梢钥闯?，這個(gè)接口聲明了兩個(gè)方法：sampleOperation1()和sampleOperation2()，而源角色Adaptee是一個(gè)具體類，它有一個(gè)sampleOperation1()方法，但是沒(méi)有sampleOperation2()方法。

public class Adaptee {
    public void sampleOperation1() {}
}

適配器角色Adapter拓展了Adaptee，同事又實(shí)現(xiàn)了目標(biāo)角色Target接口。由于Adaptee沒(méi)有提供sampleOperation2()方法，而目標(biāo)接口有要求這個(gè)方法，因此適配器角色Adapter實(shí)現(xiàn)了這個(gè)方法。

public class Adapter extends Adaptee implements Target {
    @Override
    public void sampleOperation2() {
        
    }
}

對(duì)象適配器模式

與類的適配器模式一樣，對(duì)象的適配器模式把被適配的類的API轉(zhuǎn)換成為目標(biāo)類的API，與類的適配器模式不同的是，對(duì)象的適配器模式不是使用繼承關(guān)系鏈接到Adaptee類，而是使用委派關(guān)系連接到Adaptee類。

對(duì)象的適配器模式

從上圖可以看出，Adaptee類并沒(méi)有sampleOperation2()方法，而客戶端則期待這個(gè)方法。為使客戶端能夠使用Adaptee類，需要提供一個(gè)包裝Wrapper類Adapter。這個(gè)包裝類包括了一個(gè)Adaptee的實(shí)例，從而此包裝類能夠把Adaptee的API與Traget類的API銜接起來(lái)。Adapter類與Adaptee類是委派關(guān)系，這決定了適配器模式是對(duì)象的。

示例代碼

public interface Target {
    /**
     * 這是源類Adaptee中也有的方法
     */
    public void sampleOperation1();
    /**
     * 這是源類Adaptee中沒(méi)有的方法
     */
    public void sampleOperation2();
}

public class Adaptee {
    public void sampleOperation1() {}
}

public class Adapter {
    private Adaptee adaptee;
    
    public Adapter (Adaptee adaptee) {
        this.adaptee = adaptee;
    }
    
    /**
     * 源類Adaptee有方法sampleOperation1
     * 因此適配器可以直接進(jìn)行委派
     */
    public void sampleOperation1() {
        this.adaptee.sampleOperation1();
    }
    
    /**
     * 源類Adaptee沒(méi)有方法sampleOperation2
     * 因此適配器需要自己實(shí)現(xiàn)此方法
     */
    public void sampleOperation2() {
        //
    }
}

類的適配器和對(duì)象的適配器的權(quán)衡

• 類適配器使用對(duì)象繼承的方式，是靜態(tài)的定義方式；
  對(duì)象適配器使用對(duì)象組合的方式，是動(dòng)態(tài)的組合方式。
• 對(duì)于類適配器，由于適配器直接繼承了Adaptee，使得適配器不能喝Adaptee的子類一起工作，因?yàn)殪o態(tài)是繼承的關(guān)系，而適配器繼承了Adaptee后，就不可能再去處理Adaptee的子類了。
  對(duì)于對(duì)象適配器，一個(gè)適配器可以把多種不同的源適配到同一個(gè)目標(biāo)。換言之，同一個(gè)適配器可以把源類和他的子類都適配到目標(biāo)接口。因?yàn)閷?duì)象適配器采用的是對(duì)象組合的關(guān)系，只要對(duì)象類型正確，是不是子類都無(wú)所謂。
• 對(duì)于類適配器，適配器可以重定義Adaptee的部分行為，相當(dāng)于子類覆蓋父類的部分實(shí)現(xiàn)方法。
  對(duì)于對(duì)象適配器，要重定義Adaptee的行為比較困難，這種情況下，需要定義Adaptee的子類來(lái)實(shí)現(xiàn)重定義，然后讓適配器組合子類。雖然重定義Adaptee的行為比較困難，但是想要增加一些新的行為則方便的很，而且新增加的行為可以同時(shí)適用于所有的源。
• 對(duì)于類適配器，僅僅引入了一個(gè)對(duì)象，并不需要額外的引用過(guò)來(lái)間接得到Adaptee。
  對(duì)于對(duì)象適配器，需要額外的引用來(lái)間接得到Adaptee。

建議盡量使用對(duì)象適配器的實(shí)現(xiàn)方式，多用合成/聚合，少用繼承。當(dāng)然，具體問(wèn)題還是需要具體分析，根據(jù)需要來(lái)選用實(shí)現(xiàn)方式，最適合的才是最好的。

適配器模式的優(yōu)點(diǎn)

• 更好的復(fù)用性
  系統(tǒng)需要使用現(xiàn)有的類，因此類的接口不符合系統(tǒng)的需要。那么通過(guò)適配器模式就可以讓這些功能得到更好的服用。
• 更好的拓展性
  在實(shí)現(xiàn)適配器功能的時(shí)候，可以調(diào)用自己開發(fā)的功能，從而自然的拓展系統(tǒng)的功能。

適配器模式的缺點(diǎn)

過(guò)多的使用適配器，會(huì)讓系統(tǒng)非常零亂，不易整體進(jìn)行把握。比如，明明看到調(diào)用的是A接口，其實(shí)內(nèi)部都被適配成了B接口的實(shí)現(xiàn)。一個(gè)系統(tǒng)如果太多的出現(xiàn)這種情況，無(wú)異于異常災(zāi)難。因此如果不是很有必要，可以不是用適配器，而是直接對(duì)系統(tǒng)進(jìn)行重構(gòu)。

缺省適配模式

缺省適配模式Default Adapter為一個(gè)接口提供缺省實(shí)現(xiàn)，這樣子類型可以從這個(gè)缺省實(shí)現(xiàn)進(jìn)行拓展，而不必從原有接口進(jìn)行拓展。作為適配器模式的一個(gè)特例，缺省是適配模式在Java語(yǔ)言中有著特殊的應(yīng)用。

魯智深的故事

和尚要做什么呢？吃齋、念經(jīng)、打坐、撞鐘、習(xí)武等。如果設(shè)計(jì)一個(gè)和尚接口，給出所有和尚都需要實(shí)現(xiàn)的方法，那么這個(gè)接口就應(yīng)該如下所示：

public interface 和尚 {
    public void 吃齋();
    public void 念經(jīng)();
    public void 打坐();
    public void 撞鐘();
    public void 習(xí)武();
    public String getName();
}

顯然，所有的和尚類都應(yīng)當(dāng)實(shí)現(xiàn)接口所定義的所有方法，不然根本無(wú)法通過(guò)Java語(yǔ)言編輯器。像下面的魯智深類就不行：

public class 魯智深 implements 和尚 {
    @Override
    public void 習(xí)武() {
        System.out.println("拳打鎮(zhèn)關(guān)西");
        System.out.println("大鬧五臺(tái)山");
        System.out.println("大鬧桃花村");
        System.out.println("火燒瓦官寺");
        System.out.println("倒拔垂楊柳");
    }

    @Override
    public String getName() {
        return "魯智深";
    }

}

由于魯智深只實(shí)現(xiàn)了getName()和習(xí)武()兩個(gè)方法，而沒(méi)有實(shí)現(xiàn)任何其他的方法。因此，它根本無(wú)法通過(guò)Java語(yǔ)言編輯器的檢查。魯智深類只有實(shí)現(xiàn)和尚接口的所有的方法才可以通過(guò)Java語(yǔ)言編輯器，但是這樣一來(lái)魯智深就不再是魯智深了。我們研究一下幾百年前魯智深是怎么剃度成和尚的，會(huì)對(duì)Java編程有很大的啟發(fā)。不錯(cuò)，當(dāng)初魯達(dá)剃度，眾僧說(shuō)：“此人形容丑惡、相貌兇頑，不可剃度他?！?，但是長(zhǎng)老卻說(shuō)：“此人上應(yīng)天星，心地剛直。雖然時(shí)下兇頑，命中駁雜，久后卻得清凈。證果非凡，汝等皆不及他?！薄?/p>

原來(lái)如此，看著只要這里也應(yīng)上一個(gè)天星的話，問(wèn)題就解決了！使用面向?qū)ο蟮恼Z(yǔ)言來(lái)說(shuō)，“應(yīng)”，實(shí)現(xiàn)；“天星”，抽象類。

public abstract class 天星 implements 和尚 {

    @Override
    public void 吃齋() {}

    @Override
    public void 念經(jīng)() {}

    @Override
    public void 打坐() {}

    @Override
    public void 撞鐘() {}

    @Override
    public void 習(xí)武() {}

    @Override
    public String getName() {
        return null;
    }

}

魯智深類繼承抽象類天星

public class 魯智深 extends 天星 {
    @Override
    public void 習(xí)武() {
        System.out.println("拳打鎮(zhèn)關(guān)西");
        System.out.println("大鬧五臺(tái)山");
        System.out.println("大鬧桃花村");
        System.out.println("火燒瓦官寺");
        System.out.println("倒拔垂楊柳");
    }

    @Override
    public String getName() {
        return "魯智深";
    }

}

這個(gè)抽象的天星類便是一個(gè)適配器類，魯智深實(shí)際上借助于適配器模式達(dá)到其剃度的目的。此適配器類實(shí)現(xiàn)了和尚接口所要求的所有方法。但是與通常的適配器模式不同的是，此適配器類給出的所有的方法的實(shí)現(xiàn)都是“平庸”的。這種“平庸化”的適配器模式稱為缺省適配模式。

在很多情況下，必須讓一個(gè)具體類實(shí)現(xiàn)某一個(gè)接口，但是這個(gè)類又用不到接口所規(guī)定的所有的方法。通常的處理方式是：這個(gè)具體類要實(shí)現(xiàn)所有的方法，那些有用的方法要有實(shí)現(xiàn)，那些沒(méi)有用的方法也要有空的、平庸的實(shí)現(xiàn)。

這些空的方法是一種浪費(fèi)，有時(shí)也是一種混亂。除非看過(guò)這些空方法的代碼，程序員可能會(huì)以為這些方法不是空的。即使他知道其中有一些方法是空的，也不一定知道哪些方法是空的，哪些方法不是空的。

缺省適配模式可以很好的處理這一情況?？梢栽O(shè)計(jì)一個(gè)抽象的適配器類實(shí)現(xiàn)接口，此抽象類要給接口所要求的每一種方法都提供一個(gè)空的方法。就像幫助了魯智深的“上應(yīng)天星”一樣，此抽象類可以使它的子類免于被迫實(shí)現(xiàn)空給的方法。

缺省適配模式的結(jié)構(gòu)

缺省適配模式是一種“平庸化”的適配器模式。

缺省適配模式

public interface AbstractService {
    public void serviceOperation1();
    public int serviceOperation2();
    public String serviceOperation3();
}

public abstract class DefaultAdapter implements AbstractService {
    @Override
    public void serviceOperation1() {
    }

    @Override
    public int serviceOperation2() {
        return 0;
    }

    @Override
    public String serviceOperation3() {
        return null;
    }
}

可以看出，接口AbstractService要求定義三個(gè)方法，分別為serviceOperation1()、serviceOperation2()和serviceOperation3()；而抽象適配器類DefaultAdapter則為這三種方法都提供了默認(rèn)的實(shí)現(xiàn)。因此任何繼承自抽象類DefaultAdapter的具體類都可以選擇它所需要的方法實(shí)現(xiàn)，而不必理會(huì)其他的不需要的方法。

適配器模式的用意是要改變?cè)吹慕涌冢员闩c目標(biāo)接口相容。缺省適配模式的用意稍有不同，它是為了方便建立一個(gè)不平庸的適配器類而提供的一種平庸實(shí)現(xiàn)。

在任何時(shí)候，如果不準(zhǔn)備實(shí)現(xiàn)一個(gè)接口的所有方法時(shí)，就可以使用缺省適配模式制造一個(gè)抽象類，給出所有方法的平庸的具體實(shí)現(xiàn)。這樣，從這個(gè)抽象類再繼承下去的子類就不必實(shí)現(xiàn)所有的方法了。

參考

《JAVA與模式》之適配器模式