在前端開發(fā)中，我們經(jīng)常會(huì)遇到不同模塊、庫或 API 之間的接口不兼容的情況。這可能是由于接口的變更、不同技術(shù)棧之間的差異，或是遷移項(xiàng)目時(shí)遺留下來的問題。為了解決這些問題，適配器模式提供了一種有效的解決方案。

1、什么是適配器模式？

假設(shè)你在中國買了一個(gè)新的iPhone，但是充電器的接口是美國標(biāo)準(zhǔn)，不能直接插入中國的電源插座。這時(shí)候你可以使用一個(gè)電源適配器，它一端是美標(biāo)插頭，可以連接iPhone充電器，另一端是中國標(biāo)準(zhǔn)插頭，可以插進(jìn)中國的電源插座。

這個(gè)電源適配器就扮演了適配器模式中的角色:

• 目標(biāo)(Target)接口：中國標(biāo)準(zhǔn)電源插座
• 適配者(Adaptee)：iPhone充電器的美標(biāo)接口
• 適配器(Adapter)：電源適配器，實(shí)現(xiàn)了目標(biāo)接口，同時(shí)封裝了適配者
• 客戶(Client)：你和你的iPhone 通過適配器，原本不能匹配使用的美標(biāo)充電器和中國電源接口可以一起工作，所以你可以給iPhone充電。

這就像在代碼中使用適配器模式可以讓不同的接口一起工作一樣。

適配器模式是一種結(jié)構(gòu)性設(shè)計(jì)模式，旨在將一個(gè)類的接口轉(zhuǎn)換為客戶端期望的另一種接口。這使得原本因接口不兼容而無法一起工作的類可以一起協(xié)同工作。適配器模式通過創(chuàng)建一個(gè)中間適配器類來實(shí)現(xiàn)接口的轉(zhuǎn)換，從而使得不同接口之間能夠進(jìn)行交互。

2、適配器模式的結(jié)構(gòu)和使用場景

適配器模式包含以下主要角色:

• 目標(biāo)(Target) - 定義客戶端所需的和適配器需要實(shí)現(xiàn)的接口
• 適配器(Adapter) - 轉(zhuǎn)換接口到目標(biāo)接口的適配器
• 適配者(Adaptee) - 需要適配的接口
• 客戶(Client) - 通過目標(biāo)接口調(diào)用適配器

適配器實(shí)現(xiàn)了目標(biāo)接口，同時(shí)封裝了適配者。客戶端通過目標(biāo)接口調(diào)用適配器，適配器再調(diào)用適配者接口，這樣就實(shí)現(xiàn)了接口的轉(zhuǎn)換。

適配器模式通常用于:

• 復(fù)用已有的類，而接口不匹配時(shí). 通過適配器可以使得原類和接口匹配。
• 希望復(fù)用一些現(xiàn)存的類，但是接口與業(yè)務(wù)要求不一致時(shí)。
• 需要訪問業(yè)務(wù)領(lǐng)域中的多個(gè)子系統(tǒng)的功能，而多個(gè)子系統(tǒng)具有不一致的接口時(shí)。 可以使用適配器模式構(gòu)建一個(gè)統(tǒng)一的接口，使多個(gè)子系統(tǒng)功能對外以統(tǒng)一的接口呈現(xiàn)，提高子系統(tǒng)的透明度和復(fù)用度。

3、前端開發(fā)中使用適配器模式

適配器模式在前端開發(fā)中使用廣泛,主要通過編寫適配器組件來解決不同接口不兼容的問題。下面我通過幾個(gè)例子來具體介紹。

第三方庫的接口不兼容

假設(shè)你正在使用兩個(gè)不同的圖表庫，每個(gè)庫都有自己獨(dú)特的數(shù)據(jù)格式和 API。然而，你希望在一個(gè)頁面上同時(shí)使用這兩個(gè)庫來呈現(xiàn)不同類型的圖表。通過創(chuàng)建適配器，你可以將一個(gè)庫的數(shù)據(jù)格式轉(zhuǎn)換為另一個(gè)庫所需的格式，從而實(shí)現(xiàn)兩者的協(xié)同工作。

假設(shè)我們有兩個(gè)圖表庫，一個(gè)是名為 ChartJS 的庫，另一個(gè)是名為 Highcharts 的庫。每個(gè)庫都有自己不同的數(shù)據(jù)格式和 API，我們希望能夠在同一個(gè)項(xiàng)目中使用這兩個(gè)庫。

首先，我們定義 ChartJS 和 Highcharts 兩個(gè)庫的接口：

// ChartJS 接口
interface ChartJS {
    render(data: number[]): void;
}

// Highcharts 接口
interface Highcharts {
    draw(data: number[]): void;
}

然后，我們創(chuàng)建適配器類來適配 ChartJS 到 Highcharts：

// ChartJS 到 Highcharts 的適配器
class ChartJSAdapter implements Highcharts {
    private chartJS: ChartJS;

    constructor(chartJS: ChartJS) {
        this.chartJS = chartJS;
    }

    draw(data: number[]): void {
        // 將 ChartJS 的 render 方法適配成 Highcharts 的 draw 方法
        this.chartJS.render(data);
    }
}

最后，我們可以在客戶端代碼中使用適配器來實(shí)現(xiàn)圖表的繪制：

// 使用適配器創(chuàng)建 Highcharts 實(shí)例
const chartJSInstance: ChartJS = {
    render: (data: number[]) => {
        console.log(`ChartJS rendering: ${data}`);
    }
};

const chartAdapter = new ChartJSAdapter(chartJSInstance);

// 繪制圖表
const data = [10, 20, 30, 40, 50];
chartAdapter.draw(data);

在這個(gè)示例中，我們創(chuàng)建了一個(gè)適配器類 ChartJSAdapter，它實(shí)現(xiàn)了 Highcharts 接口，但在內(nèi)部使用了 ChartJS 實(shí)例。適配器的 draw 方法將 ChartJS 的 render 方法適配成了 Highcharts 的 draw 方法，從而使得我們可以在不同的庫之間進(jìn)行適配。

不同平臺(tái)之間的兼容性

在不同瀏覽器平臺(tái)可能具有不同的界面和 API 要求，通過創(chuàng)建適配器可以用來抹平這些差異，你可以根據(jù)目標(biāo)平臺(tái)的需求適配相應(yīng)的界面元素和功能，從而實(shí)現(xiàn)代碼的重用和跨平臺(tái)開發(fā)。

例如，我們需要編程式獲取頁面滾動(dòng)位置：

interface ScrollPositionReader {
  getScrollPosition(): {x: number, y: number}; 
}

而不同瀏覽器有不同的獲取滾動(dòng)位置方法：

// Chrome, Firefox等
window.scrollX
window.scrollY

// IE8及以下
document.body.scrollLeft
document.body.scrollTop

為了統(tǒng)一接口，我們可以編寫適配器：

class ScrollPositionAdapter implements ScrollPositionReader {

  getScrollPosition() {
    if (window.scrollX != null) {
      return {
        x: window.scrollX,
        y: window.scrollY  
      }
    } else {
      return {
        x: document.body.scrollLeft,
        y: document.body.scrollTop
      }
    }
  }

}

然后就可以通過統(tǒng)一的ScrollPositionReader接口獲取滾動(dòng)位置了：

const positionReader = new ScrollPositionAdapter();
const pos = positionReader.getScrollPosition();

這樣，適配器幫我們解決了不同瀏覽器接口的不兼容問題。在前端工程化配置中，babel和ployfill也使用了適配器模式，將代碼進(jìn)行編譯，來實(shí)現(xiàn)對不同瀏覽器版本的兼容。

適配后端接口變更

當(dāng)后端 API 發(fā)生變更時(shí)，前端可能需要進(jìn)行大量修改以適應(yīng)新的數(shù)據(jù)結(jié)構(gòu)和字段。通過創(chuàng)建適配器，你可以將新的 API 響應(yīng)轉(zhuǎn)換為前端舊代碼所期望的數(shù)據(jù)格式，從而避免全面修改現(xiàn)有代碼。

假設(shè)我們的應(yīng)用中使用了一個(gè)名為 OldAPI 的舊版 API，但由于后端的變更，API 的響應(yīng)數(shù)據(jù)格式發(fā)生了改變。我們希望在不改變現(xiàn)有代碼的情況下，適應(yīng)新的數(shù)據(jù)格式。

首先，我們定義 OldAPI 的舊版和新版接口：

// 舊版 OldAPI 接口
interface OldAPI {
    requestData(): string;
}

// 新版 OldAPI 接口
interface NewAPI {
    requestNewData(): string;
}

然后，我們創(chuàng)建適配器類來適配舊版 OldAPI 到新版 NewAPI：

// 適配舊版 OldAPI 到新版 NewAPI 的適配器
class OldAPIToNewAdapter implements NewAPI {
    private oldAPI: OldAPI;

    constructor(oldAPI: OldAPI) {
        this.oldAPI = oldAPI;
    }

    requestNewData(): string {
        const oldData = this.oldAPI.requestData();
        // 對舊數(shù)據(jù)進(jìn)行適配轉(zhuǎn)換
        const newData = `${oldData} (adapted)`;
        return newData;
    }
}

最后，我們可以在客戶端代碼中使用適配器來請求新版數(shù)據(jù)：

// 使用適配器創(chuàng)建 NewAPI 實(shí)例
const oldAPIInstance: OldAPI = {
    requestData: () => {
        return "Old data";
    }
};

const apiAdapter = new OldAPIToNewAdapter(oldAPIInstance);

// 請求新版數(shù)據(jù)
const newData = apiAdapter.requestNewData();
console.log(newData);

在這個(gè)示例中，我們創(chuàng)建了一個(gè)適配器類 OldAPIToNewAdapter，它實(shí)現(xiàn)了新版 NewAPI 接口，但在內(nèi)部使用了舊版 OldAPI 實(shí)例。適配器的 requestNewData 方法將舊版 API 的響應(yīng)數(shù)據(jù)進(jìn)行了適配轉(zhuǎn)換，使得舊版 API 的響應(yīng)能夠適應(yīng)新版接口的需求。

用適配器進(jìn)行Mock模擬

當(dāng)涉及使用適配器來進(jìn)行 Mock 模擬時(shí)，我們可以考慮一個(gè)場景：一個(gè)應(yīng)用需要從后端獲取用戶信息，但是在開發(fā)階段，后端可能還沒有完全實(shí)現(xiàn)，或者我們希望在測試中使用模擬的數(shù)據(jù)。我們可以使用適配器來模擬后端 API，以便在開發(fā)和測試中使用。

首先，我們定義一個(gè)用戶信息的接口，用于后端 API 和適配器的標(biāo)準(zhǔn)：

interface UserInfo {
    id: number;
    name: string;
    email: string;
}

然后，我們創(chuàng)建一個(gè)后端 API 接口，模擬后端實(shí)際返回的數(shù)據(jù)：

interface BackendAPI {
    getUserInfo(userId: number): UserInfo;
}

接下來，我們可以創(chuàng)建一個(gè)適配器來模擬后端 API，以便在開發(fā)和測試中使用：

class MockBackendAdapter implements BackendAPI {
    getUserInfo(userId: number): UserInfo {
        // 模擬返回用戶信息
        return {
            id: userId,
            name: "Mock User",
            email: "mock@example.com"
        };
    }
}

最后，我們可以在應(yīng)用中使用適配器來獲取用戶信息：

function getAppUserInfo(api: BackendAPI, userId: number): UserInfo {
    return api.getUserInfo(userId);
}

// 在開發(fā)階段使用模擬的后端適配器
const mockBackend = new MockBackendAdapter();
const userInfo = getAppUserInfo(mockBackend, 123);
console.log(userInfo);

在這個(gè)示例中，我們使用適配器 MockBackendAdapter 來模擬后端 API。適配器實(shí)現(xiàn)了 BackendAPI 接口，但在內(nèi)部返回了模擬的用戶信息數(shù)據(jù)。通過這種方式，我們可以在開發(fā)階段使用模擬數(shù)據(jù)來測試應(yīng)用的功能，而無需等待實(shí)際后端開發(fā)完成。

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

適配器模式是一個(gè)有力的設(shè)計(jì)工具，可以幫助我們處理不同接口之間的兼容性問題，提高代碼的可維護(hù)性和可擴(kuò)展性。然而，開發(fā)者需要在使用適配器時(shí)謹(jǐn)慎權(quán)衡其優(yōu)缺點(diǎn)，確保在特定情況下它能夠真正帶來價(jià)值。以下是適配器模式的優(yōu)缺點(diǎn)。

（1）優(yōu)點(diǎn)

• 解耦代碼： 適配器模式可以幫助解耦不同模塊之間的依賴關(guān)系，使它們能夠獨(dú)立演化和維護(hù)。這有助于降低代碼的耦合度，提高代碼的可維護(hù)性和可擴(kuò)展性。
• 重用既有代碼： 適配器模式允許我們在不修改現(xiàn)有代碼的情況下，適應(yīng)新的接口或需求。這使得我們能夠重用既有的代碼，減少重復(fù)勞動(dòng)和開發(fā)成本。
• 平滑遷移： 當(dāng)項(xiàng)目需要進(jìn)行遷移或升級時(shí)，適配器模式可以幫助我們平滑過渡。通過創(chuàng)建適配器，我們可以將舊的接口適配成新的接口，從而避免全面修改現(xiàn)有代碼。
• 靈活性和擴(kuò)展性： 適配器模式可以為系統(tǒng)引入一層靈活的中間層，從而使得系統(tǒng)更具有擴(kuò)展性。新的適配器可以輕松添加，以適應(yīng)未來可能出現(xiàn)的變化。

（2）缺點(diǎn)：

• 引入復(fù)雜性： 使用適配器模式可能會(huì)引入一些額外的類和層級，增加代碼的復(fù)雜性。開發(fā)者需要仔細(xì)權(quán)衡是否值得引入適配器來解決接口兼容性問題。
• 運(yùn)行時(shí)開銷： 在運(yùn)行時(shí)執(zhí)行適配轉(zhuǎn)換可能會(huì)引入一些運(yùn)行時(shí)開銷，特別是在大規(guī)模數(shù)據(jù)轉(zhuǎn)換時(shí)。這可能會(huì)對應(yīng)用的性能產(chǎn)生影響。
• 設(shè)計(jì)合理性： 使用適配器模式時(shí)，需要確保適配器的設(shè)計(jì)合理性，以確保適配器類的職責(zé)清晰，并且不會(huì)引入額外的復(fù)雜性。

5、總結(jié)

適配器模式是前端開發(fā)中的一個(gè)重要設(shè)計(jì)模式，可以幫助我們解決不同接口之間的兼容性問題。通過創(chuàng)建適配器類，我們可以將不兼容的接口轉(zhuǎn)換為可互操作的形式，實(shí)現(xiàn)模塊之間的協(xié)同工作。

在 TypeScript 中，適配器模式可以通過創(chuàng)建中間適配器類來實(shí)現(xiàn)，從而實(shí)現(xiàn)代碼的解耦和重用。

在實(shí)際開發(fā)中，適配器模式常用于處理第三方庫的接口兼容性問題、應(yīng)對 API 的變更以及實(shí)現(xiàn)跨平臺(tái)開發(fā)。然而，開發(fā)者需要在使用適配器模式時(shí)權(quán)衡其優(yōu)缺點(diǎn)，確保其對項(xiàng)目的長期維護(hù)和可擴(kuò)展性沒有負(fù)面影響。

通過合理的設(shè)計(jì)和實(shí)踐，適配器模式將成為前端開發(fā)中的有力工具，幫助我們更好地管理和整合不同模塊和技術(shù)。