iOS設(shè)計(jì)模式-適配器模式

適配器模式:將復(fù)用類的接口轉(zhuǎn)換成客戶端希望的接口。(本質(zhì)上就是復(fù)用的類的接口不能滿足當(dāng)前項(xiàng)目的需要,Adapter 模式使得原本由于接口不兼容而不能一起工作的復(fù)用類與現(xiàn)有項(xiàng)目兼容)

適用場(chǎng)景:1.已經(jīng)存在的類的接口不符合我們的需求;
2.創(chuàng)建一個(gè)可以復(fù)用的類,使得該類可以與其他不相關(guān)的類或不可預(yù)見(jiàn)的類(即那些接口可能不一定兼容的類)協(xié)同工作;
3.在不對(duì)每一個(gè)都進(jìn)行子類化以匹配它們的接口的情況下,使用一些已經(jīng)存在的子類。

適配器模式分為類適配器和對(duì)象適配器兩種實(shí)現(xiàn)方式。

1.類適配器

要在OC中實(shí)現(xiàn)類適配器,首先需要有定義了客戶端要使用的一套行為的協(xié)議,然后要用具體的適配器類來(lái)實(shí)現(xiàn)這個(gè)協(xié)議。適配器類同時(shí)也要繼承被適配者。類適配器結(jié)構(gòu)圖如下所示:
類適配器結(jié)構(gòu).jpeg

從圖中可以看到,Adapter是一個(gè)Target類型,同時(shí)也是Adaptee類型。它重載了Target的request方法,沒(méi)有重載Adaptee中的specificRequest方法,而是在Adapter的request方法的實(shí)現(xiàn)中,調(diào)用父類的specificRequest方法。只有當(dāng)Target是協(xié)議而不是類時(shí),類適配器才能夠用OC來(lái)實(shí)現(xiàn),因?yàn)镺C中是沒(méi)有多重繼承的。

2.對(duì)象適配器

與類適配器不同,對(duì)象適配器不繼承被適配者,而是組合了一個(gè)對(duì)它的引用。對(duì)象適配器結(jié)構(gòu)圖如下所示:
對(duì)象適配器結(jié)構(gòu)

從兩個(gè)結(jié)構(gòu)圖可以看到,Target和Adapter的關(guān)系相同,Adapter和Adaptee之間的關(guān)系,由繼承變成了關(guān)聯(lián)。這種關(guān)系下,Adapter需要保持一個(gè)對(duì)Adaptee的引用。在request方法中,Adapter發(fā)送[_adaptee specificRequest]消息給Adaptee,以完成客戶端的請(qǐng)求。

小結(jié)

適配器模式主要應(yīng)用于“希望復(fù)用一些現(xiàn)存的類,但是接口又與復(fù)用環(huán)境要求不一致的情況”,在遺留代碼復(fù)用、類庫(kù)遷移等方面非常有用。

適配器模式有對(duì)象適配器和類適配器兩種形式的實(shí)現(xiàn)結(jié)構(gòu),但是類適配器采用“多繼承”的實(shí)現(xiàn)方式,帶來(lái)了不良的高耦合,所以一般不推薦使用,另外,OC中也不支持多重繼承。對(duì)象適配器采用“對(duì)象組合”的方式,更符合松耦合規(guī)范。

在以下各種情況下可以考慮使用適配器模式:
需要使用一個(gè)已經(jīng)存在的類,而它的接口不符合新環(huán)境的規(guī)范。
想創(chuàng)建一個(gè)可以復(fù)用的類,該類可以與其他不相關(guān)的類或不可預(yù)見(jiàn)的類(即那些接口可能不一定兼容的類)協(xié)同工作。
代碼

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容