Adapter適配器模式怎么應(yīng)用

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

Adapter（適配器模式）

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

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

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

舉例子

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

接口轉(zhuǎn)換器

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

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

接口轉(zhuǎn)換器就是我們?cè)谏钪惺褂玫降倪m配器模式，因?yàn)閺S商并沒有生產(chǎn)一個(gè)新的插座，我們也沒有因?yàn)榻涌诓贿m配而換一個(gè)手機(jī)，一切只需要一個(gè)接口轉(zhuǎn)換器即可，這就是運(yùn)用設(shè)計(jì)模式的收益。

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

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

對(duì) ORM 來說，屏蔽不同平臺(tái)的差異，就是利用適配器模式做到的。

API Deprecated

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

意圖解釋

上面三個(gè)例子都滿足下面兩個(gè)條件：

API 不兼容：因?yàn)榻涌诘牟煌?；?shù)據(jù)庫 SQL 語法的不同；框架 API 的不同。

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

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

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

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

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

下面是名詞解釋：

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

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

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

繼承：

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

組合：

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

代碼例子

下面例子使用 typescript 編寫。

繼承：

interface ITarget {

  // 標(biāo)準(zhǔn)方式是 hello

  hello: () => void

}

class Adaptee {

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

  sayHello() {

    console.log('hello')

  }

}

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

class Adapter extends Adaptee implements ITarget {

  hello() {

    // 用 sayHello 對(duì)接到 hello

    super.sayHello()

  }

}

組合：

interface ITarget {

  // 標(biāo)準(zhǔn)方式是 hello

  hello: () => void

}

class Adaptee {

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

  sayHello() {

    console.log('hello')

  }

}

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

class Adapter implements ITarget {

  private adaptee: Adaptee 

  constructor(adaptee: Adaptee) {

    this.adaptee = adaptee

  }

  hello() {

    // 用 adaptee.sayHello 對(duì)接到 hello

    this.adaptee.sayHello()

  }

}

弊端

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

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

三方包適配。

新舊 API 兼容。

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

感謝各位的閱讀，以上就是“Adapter適配器模式怎么應(yīng)用”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)Adapter適配器模式怎么應(yīng)用這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！