三言兩語說透設計模式的藝術-適配器模式
在前端開發中,我們經常會遇到不同模塊、庫或 API 之間的接口不兼容的情況。這可能是由于接口的變更、不同技術棧之間的差異,或是遷移項目時遺留下來的問題。為了解決這些問題,適配器模式提供了一種有效的解決方案。
1、什么是適配器模式?
假設你在中國買了一個新的iPhone,但是充電器的接口是美國標準,不能直接插入中國的電源插座。這時候你可以使用一個電源適配器,它一端是美標插頭,可以連接iPhone充電器,另一端是中國標準插頭,可以插進中國的電源插座。
這個電源適配器就扮演了適配器模式中的角色:
- 目標(Target)接口:中國標準電源插座
- 適配者(Adaptee):iPhone充電器的美標接口
- 適配器(Adapter):電源適配器,實現了目標接口,同時封裝了適配者
- 客戶(Client):你和你的iPhone 通過適配器,原本不能匹配使用的美標充電器和中國電源接口可以一起工作,所以你可以給iPhone充電。
這就像在代碼中使用適配器模式可以讓不同的接口一起工作一樣。
適配器模式是一種結構性設計模式,旨在將一個類的接口轉換為客戶端期望的另一種接口。這使得原本因接口不兼容而無法一起工作的類可以一起協同工作。適配器模式通過創建一個中間適配器類來實現接口的轉換,從而使得不同接口之間能夠進行交互。
2、適配器模式的結構和使用場景
適配器模式包含以下主要角色:
- 目標(Target) - 定義客戶端所需的和適配器需要實現的接口
- 適配器(Adapter) - 轉換接口到目標接口的適配器
- 適配者(Adaptee) - 需要適配的接口
- 客戶(Client) - 通過目標接口調用適配器
適配器實現了目標接口,同時封裝了適配者。客戶端通過目標接口調用適配器,適配器再調用適配者接口,這樣就實現了接口的轉換。
適配器模式通常用于:
- 復用已有的類,而接口不匹配時. 通過適配器可以使得原類和接口匹配。
- 希望復用一些現存的類,但是接口與業務要求不一致時。
- 需要訪問業務領域中的多個子系統的功能,而多個子系統具有不一致的接口時。 可以使用適配器模式構建一個統一的接口,使多個子系統功能對外以統一的接口呈現,提高子系統的透明度和復用度。
3、前端開發中使用適配器模式
適配器模式在前端開發中使用廣泛,主要通過編寫適配器組件來解決不同接口不兼容的問題。下面我通過幾個例子來具體介紹。
第三方庫的接口不兼容
假設你正在使用兩個不同的圖表庫,每個庫都有自己獨特的數據格式和 API。然而,你希望在一個頁面上同時使用這兩個庫來呈現不同類型的圖表。通過創建適配器,你可以將一個庫的數據格式轉換為另一個庫所需的格式,從而實現兩者的協同工作。
假設我們有兩個圖表庫,一個是名為 ChartJS 的庫,另一個是名為 Highcharts 的庫。每個庫都有自己不同的數據格式和 API,我們希望能夠在同一個項目中使用這兩個庫。
首先,我們定義 ChartJS 和 Highcharts 兩個庫的接口:
// ChartJS 接口
interface ChartJS {
render(data: number[]): void;
}
// Highcharts 接口
interface Highcharts {
draw(data: number[]): void;
}
然后,我們創建適配器類來適配 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);
}
}
最后,我們可以在客戶端代碼中使用適配器來實現圖表的繪制:
// 使用適配器創建 Highcharts 實例
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);
在這個示例中,我們創建了一個適配器類 ChartJSAdapter,它實現了 Highcharts 接口,但在內部使用了 ChartJS 實例。適配器的 draw 方法將 ChartJS 的 render 方法適配成了 Highcharts 的 draw 方法,從而使得我們可以在不同的庫之間進行適配。
不同平臺之間的兼容性
在不同瀏覽器平臺可能具有不同的界面和 API 要求,通過創建適配器可以用來抹平這些差異,你可以根據目標平臺的需求適配相應的界面元素和功能,從而實現代碼的重用和跨平臺開發。
例如,我們需要編程式獲取頁面滾動位置:
interface ScrollPositionReader {
getScrollPosition(): {x: number, y: number};
}
而不同瀏覽器有不同的獲取滾動位置方法:
// Chrome, Firefox等
window.scrollX
window.scrollY
// IE8及以下
document.body.scrollLeft
document.body.scrollTop
為了統一接口,我們可以編寫適配器:
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
}
}
}
}
然后就可以通過統一的ScrollPositionReader接口獲取滾動位置了:
const positionReader = new ScrollPositionAdapter();
const pos = positionReader.getScrollPosition();
這樣,適配器幫我們解決了不同瀏覽器接口的不兼容問題。在前端工程化配置中,babel和ployfill也使用了適配器模式,將代碼進行編譯,來實現對不同瀏覽器版本的兼容。
適配后端接口變更
當后端 API 發生變更時,前端可能需要進行大量修改以適應新的數據結構和字段。通過創建適配器,你可以將新的 API 響應轉換為前端舊代碼所期望的數據格式,從而避免全面修改現有代碼。
假設我們的應用中使用了一個名為 OldAPI 的舊版 API,但由于后端的變更,API 的響應數據格式發生了改變。我們希望在不改變現有代碼的情況下,適應新的數據格式。
首先,我們定義 OldAPI 的舊版和新版接口:
// 舊版 OldAPI 接口
interface OldAPI {
requestData(): string;
}
// 新版 OldAPI 接口
interface NewAPI {
requestNewData(): string;
}
然后,我們創建適配器類來適配舊版 OldAPI 到新版 NewAPI:
// 適配舊版 OldAPI 到新版 NewAPI 的適配器
class OldAPIToNewAdapter implements NewAPI {
private oldAPI: OldAPI;
constructor(oldAPI: OldAPI) {
this.oldAPI = oldAPI;
}
requestNewData(): string {
const oldData = this.oldAPI.requestData();
// 對舊數據進行適配轉換
const newData = `${oldData} (adapted)`;
return newData;
}
}
最后,我們可以在客戶端代碼中使用適配器來請求新版數據:
// 使用適配器創建 NewAPI 實例
const oldAPIInstance: OldAPI = {
requestData: () => {
return "Old data";
}
};
const apiAdapter = new OldAPIToNewAdapter(oldAPIInstance);
// 請求新版數據
const newData = apiAdapter.requestNewData();
console.log(newData);
在這個示例中,我們創建了一個適配器類 OldAPIToNewAdapter,它實現了新版 NewAPI 接口,但在內部使用了舊版 OldAPI 實例。適配器的 requestNewData 方法將舊版 API 的響應數據進行了適配轉換,使得舊版 API 的響應能夠適應新版接口的需求。
用適配器進行Mock模擬
當涉及使用適配器來進行 Mock 模擬時,我們可以考慮一個場景:一個應用需要從后端獲取用戶信息,但是在開發階段,后端可能還沒有完全實現,或者我們希望在測試中使用模擬的數據。我們可以使用適配器來模擬后端 API,以便在開發和測試中使用。
首先,我們定義一個用戶信息的接口,用于后端 API 和適配器的標準:
interface UserInfo {
id: number;
name: string;
email: string;
}
然后,我們創建一個后端 API 接口,模擬后端實際返回的數據:
interface BackendAPI {
getUserInfo(userId: number): UserInfo;
}
接下來,我們可以創建一個適配器來模擬后端 API,以便在開發和測試中使用:
class MockBackendAdapter implements BackendAPI {
getUserInfo(userId: number): UserInfo {
// 模擬返回用戶信息
return {
id: userId,
name: "Mock User",
email: "mock@example.com"
};
}
}
最后,我們可以在應用中使用適配器來獲取用戶信息:
function getAppUserInfo(api: BackendAPI, userId: number): UserInfo {
return api.getUserInfo(userId);
}
// 在開發階段使用模擬的后端適配器
const mockBackend = new MockBackendAdapter();
const userInfo = getAppUserInfo(mockBackend, 123);
console.log(userInfo);
在這個示例中,我們使用適配器 MockBackendAdapter 來模擬后端 API。適配器實現了 BackendAPI 接口,但在內部返回了模擬的用戶信息數據。通過這種方式,我們可以在開發階段使用模擬數據來測試應用的功能,而無需等待實際后端開發完成。
4、適配器模式的優缺點
適配器模式是一個有力的設計工具,可以幫助我們處理不同接口之間的兼容性問題,提高代碼的可維護性和可擴展性。然而,開發者需要在使用適配器時謹慎權衡其優缺點,確保在特定情況下它能夠真正帶來價值。以下是適配器模式的優缺點。
(1)優點
- 解耦代碼: 適配器模式可以幫助解耦不同模塊之間的依賴關系,使它們能夠獨立演化和維護。這有助于降低代碼的耦合度,提高代碼的可維護性和可擴展性。
- 重用既有代碼: 適配器模式允許我們在不修改現有代碼的情況下,適應新的接口或需求。這使得我們能夠重用既有的代碼,減少重復勞動和開發成本。
- 平滑遷移: 當項目需要進行遷移或升級時,適配器模式可以幫助我們平滑過渡。通過創建適配器,我們可以將舊的接口適配成新的接口,從而避免全面修改現有代碼。
- 靈活性和擴展性: 適配器模式可以為系統引入一層靈活的中間層,從而使得系統更具有擴展性。新的適配器可以輕松添加,以適應未來可能出現的變化。
(2)缺點:
- 引入復雜性: 使用適配器模式可能會引入一些額外的類和層級,增加代碼的復雜性。開發者需要仔細權衡是否值得引入適配器來解決接口兼容性問題。
- 運行時開銷: 在運行時執行適配轉換可能會引入一些運行時開銷,特別是在大規模數據轉換時。這可能會對應用的性能產生影響。
- 設計合理性: 使用適配器模式時,需要確保適配器的設計合理性,以確保適配器類的職責清晰,并且不會引入額外的復雜性。
5、總結
適配器模式是前端開發中的一個重要設計模式,可以幫助我們解決不同接口之間的兼容性問題。通過創建適配器類,我們可以將不兼容的接口轉換為可互操作的形式,實現模塊之間的協同工作。
在 TypeScript 中,適配器模式可以通過創建中間適配器類來實現,從而實現代碼的解耦和重用。
在實際開發中,適配器模式常用于處理第三方庫的接口兼容性問題、應對 API 的變更以及實現跨平臺開發。然而,開發者需要在使用適配器模式時權衡其優缺點,確保其對項目的長期維護和可擴展性沒有負面影響。
通過合理的設計和實踐,適配器模式將成為前端開發中的有力工具,幫助我們更好地管理和整合不同模塊和技術。