這篇文章主要講解了“Adapter適配器模式怎么應用”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Adapter適配器模式怎么應用”吧！

十年的德清網(wǎng)站建設經(jīng)驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。成都營銷網(wǎng)站建設的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調(diào)整德清建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)建站從事“德清網(wǎng)站設計”,“德清網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

Adapter（適配器模式）

Adapter（適配器模式）屬于結(jié)構(gòu)型模式，別名 wrapper，結(jié)構(gòu)性模式關注的是如何組合類與對象，以獲得更大的結(jié)構(gòu)，我們平常工作大部分時間都在與這種設計模式打交道。

意圖：將一個類的接口轉(zhuǎn)換成客戶希望的另一個接口。Adapter 模式使得原本由于接口不兼容而不能在一起工作的那些類可以一起工作。

這個設計模式的意圖很好懂，就是把接口不兼容問題抹平。注意，也僅僅能解決接口不一致的問題，而不能解決功能不一致的問題。

舉例子

如果看不懂上面的意圖介紹，沒有關系，設計模式需要在日常工作里用起來，結(jié)合例子可以加深你的理解，下面我準備了三個例子，讓你體會什么場景下會用到這種設計模式。

接口轉(zhuǎn)換器

插座的種類很多，我們都用過許多適配器，將不同的插頭進行轉(zhuǎn)換，可以在不替換插座的情況下正常使用。

USB 接口轉(zhuǎn)換也同樣精彩，有將 TypeC 接口轉(zhuǎn)換為 TypeA 的，也有將 TypeA 接口轉(zhuǎn)換為 TypeC 的，支持雙向轉(zhuǎn)換。

接口轉(zhuǎn)換器就是我們在生活中使用到的適配器模式，因為廠商并沒有生產(chǎn)一個新的插座，我們也沒有因為接口不適配而換一個手機，一切只需要一個接口轉(zhuǎn)換器即可，這就是運用設計模式的收益。

數(shù)據(jù)庫 ORM

ORM 屏蔽了 SQL 這一層，帶來的好處是不需要理解不同 SQL 語法之間的區(qū)別，對于通用功能，ORM 會根據(jù)不同的平臺，比如 Postgresql、MySQL 進行 SQL 的轉(zhuǎn)換。

對 ORM 來說，屏蔽不同平臺的差異，就是利用適配器模式做到的。

API Deprecated

當一個廣泛使用的庫進行了含有 break change 的升級時，往往要留給開發(fā)者足夠的時間去升級，而不能升級后就直接掛掉，因此被廢棄的 API 要標記為 deprecated，而這種被廢棄標記的 API 的實際實現(xiàn)，往往是使用新的 API 替代，這種場景正是使用了適配器模式，將新的 API 適配到舊的 API，實現(xiàn) API Deprecated。

意圖解釋

上面三個例子都滿足下面兩個條件：

API 不兼容：因為接口的不同；數(shù)據(jù)庫 SQL 語法的不同；框架 API 的不同。

但能力已支持：插座都擁有充電或讀取能力；不同的 SQL 都擁有查詢數(shù)據(jù)庫能力；新 API 覆蓋了舊 API 的能力。

這樣就可以通過適配器滿足 Adapter 的意圖：

意圖：將一個類的接口轉(zhuǎn)換成客戶希望的另一個接口。Adapter 模式使得原本由于接口不兼容而不能在一起工作的那些類可以一起工作。

結(jié)構(gòu)圖

適配器的實現(xiàn)分為繼承與組合模式。

下面是名詞解釋：

Adapter 適配器，把 Adeptee 適配成 Target。

Adaptee 被適配的內(nèi)容，比如不兼容的接口。

Target 適配為的內(nèi)容，比如需要用的接口。

繼承：

適配器繼承 Adaptee 并實現(xiàn) Target，適用場景是 Adaptee 與 Target 結(jié)構(gòu)類似的情況，因為這樣只需要實現(xiàn)部分差異化即可。

組合：

組合的拓展性更強，但工作量更大，如果 Target 與 Adaptee 結(jié)構(gòu)差異較大，適合用組合模式。

代碼例子

下面例子使用 typescript 編寫。

繼承：

interface ITarget {

  // 標準方式是 hello

  hello: () => void

}

class Adaptee {

  // 要被適配的類方法叫 sayHello

  sayHello() {

    console.log('hello')

  }

}

// 適配器繼承 Adaptee 并實現(xiàn) ITarget

class Adapter extends Adaptee implements ITarget {

  hello() {

    // 用 sayHello 對接到 hello

    super.sayHello()

  }

}

組合：

interface ITarget {

  // 標準方式是 hello

  hello: () => void

}

class Adaptee {

  // 要被適配的類方法叫 sayHello

  sayHello() {

    console.log('hello')

  }

}

// 適配器繼承 Adaptee 并實現(xiàn) ITarget

class Adapter implements ITarget {

  private adaptee: Adaptee 

  constructor(adaptee: Adaptee) {

    this.adaptee = adaptee

  }

  hello() {

    // 用 adaptee.sayHello 對接到 hello

    this.adaptee.sayHello()

  }

}

弊端

使用適配器模式本身就可能是個問題，因為一個好的系統(tǒng)內(nèi)部不應該做任何僑界，模型應該保持一致性。只有在如下情況才考慮使用適配器模式：

新老系統(tǒng)接替，改造成本非常高。

三方包適配。

新舊 API 兼容。

統(tǒng)一多個類的接口。一般可以結(jié)合工廠方法使用。

感謝各位的閱讀，以上就是“Adapter適配器模式怎么應用”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對Adapter適配器模式怎么應用這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！