前言
前面所涉及的工廠設計模式和建造者設計模式都是創(chuàng)建型模式。
而今天所講解的適配器設計模式涉及到類與類的關系。
類與類的關系主要有兩種:繼承與組合,優(yōu)先使用組合。而適配器模式就用到了組合。
定義
Adapter:定義一個包裝類,用于包容不兼容接口的對象。
包裝類->適配器Adapter
被包裝對象->適配者Adaptee->被適配的類
作用:把一個類的接口轉換成客戶端所期待的另一種接口,從而使原本接口不匹配而無法一起工作的兩個類一起工作。
類的適配器模式
簡述:Target期待調用Request方法,而Adaptee中沒有(這就是所謂的不兼容現(xiàn)象)。
解決方案:為使Target能夠使用Adaptee類里的SpecificRequest方法,所以提供一個中間環(huán)節(jié)Adapter類(繼承Adaptee,實現(xiàn)Target接口),把Adapter的API和Target的API銜接起來(適配)。
package 設計模式3
/**
*@Description
*@Author PC
*@QQ 1578684787
*/
/**
* 目標接口:Target
*/
interface Target{
fun request()
}
/**
* 類源:Adaptee
*/
open class Adaptee{
fun selfRequest(){
println("selfRequest被調用了")
}
}
/**
* 適配器類
*/
class Adapter:Adaptee(),Target{
override fun request() {
this.selfRequest()
}
}
/**
* 測試
*/
fun main() {
val adapter = Adapter()
adapter.request()
}

測試結果
對象的適配器模式
概述:Target期待調用Request方法,而Adapter并沒有(不兼容現(xiàn)象)。
解決方案:為使Target能夠使用Adaptee類中的SpecificRequest方法,故提供一個中間環(huán)節(jié)Adapter類(繼承Adapter,實現(xiàn)Target接口),把Adapter的API和Target的API銜接起來(適配)。
package 設計模式3
/**
*@Description
*@Author PC
*@QQ 1578684787
*/
/**
* 目標接口
*/
interface Target1{
fun request()
}
/**
* 源類
*/
open class Adaptee1{
fun selfRequest(){
println("selfRequest1被調用了")
}
}
/**
* 適配器類
*/
class Adapter1(val adaptee: Adaptee1):Adaptee1(),Target1{
override fun request() {
adaptee.selfRequest()
}
}
/**
* 測試
*/
fun main() {
val adapter1 = Adapter1(Adaptee1())
adapter1.request()
}

測試
優(yōu)點
- 更好的復用性:系統(tǒng)需要使用現(xiàn)有的類,而此類的接口不符合系統(tǒng)的需要。那么通過適配器模式就可以讓這些功能得到更好的復用。
- 透明、簡單:客戶端可以調用同一端口,因而對客戶端來說是透明的。這用做更簡單并且更直接。
- 更好的擴展性:在實現(xiàn)適配器功能的時候,可以調用自己開發(fā)的功能,從而自然地擴展系統(tǒng)的功能。
- 解耦性:將目標和適配者類解耦,通過引入一個適配器類重用現(xiàn)有的適配者類,而無需修改源代碼。
- 符合開放-關閉原則:同一個適配器可以把適配者類和它的子類都適配到目標接口;可以為不同的目標接口實現(xiàn)不同的適配器,而不需要修改待適配類。
缺點
過多的使用適配器,會讓系統(tǒng)非常凌亂,不易進行整體把握。
應用場景
Android系統(tǒng)中的使用:ListView和RecyclerView中均用到了適配器Adapter
- 系統(tǒng)需要重用現(xiàn)有類,而該類的接口不符合系統(tǒng)的需求,可以使用適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
- 多個組件功能類似,但接口不統(tǒng)一且可能會經(jīng)常切換時,可使用適配器模式,使得客戶端可以用統(tǒng)一的接口使用它們。
參考文章:
Android設計模式-適配器模式