Go 設(shè)計(jì)模式|項(xiàng)目依賴耦合度太高?可以用適配器做下優(yōu)化
大家好,這里是每周都在陪你進(jìn)步的網(wǎng)管~!今天介紹一個(gè)在我們?cè)陂_發(fā)做項(xiàng)目時(shí),經(jīng)常會(huì)用到的設(shè)計(jì)模式—適配器模式。
適配器模式(Adapter Pattern)又叫作變壓器模式,它的功能是將一個(gè)類的接口變成客戶端所期望的另一種接口,從而使原本因接口不匹配而導(dǎo)致無(wú)法在一起工作的兩個(gè)類能夠一起工作,屬于結(jié)構(gòu)型設(shè)計(jì)模式。
適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以在一起工作。
我們用UML類圖看一下適配器模式的構(gòu)成
適配器模式的結(jié)構(gòu)
類圖-適配器模式的結(jié)構(gòu)
適配器模式中的角色構(gòu)成如下:
- 客戶端(Client):首先是客戶端,這里的客戶端可以理解成通過(guò)適配器調(diào)用服務(wù)的代碼程序,代碼只需通過(guò)接口與適配器交互即可, 無(wú)需與具體的適配器類耦合。
- 客戶端接口(Client Interface):這個(gè)接口也可被叫做適配器接口,描述了被適配的類與客戶端代碼協(xié)作時(shí)必須遵循的約定。
- 適配器 (Adapter): 作為同時(shí)與客戶端和服務(wù)交互的中介類: 它在實(shí)現(xiàn)客戶端接口的同時(shí)封裝了服務(wù)對(duì)象。 適配器接受客戶端通過(guò)適配器接口發(fā)起的調(diào)用, 并將其轉(zhuǎn)換為適用于被封裝服務(wù)對(duì)象的調(diào)用。
- 服務(wù)(Service):服務(wù)通常是一些第三方功能類庫(kù)或者是一些遺留系統(tǒng)的功能類,客戶端與其不兼容,因此無(wú)法直接調(diào)用其功能,需要適配器進(jìn)行轉(zhuǎn)換。
通過(guò)上面的類圖里各個(gè)角色類的關(guān)聯(lián)我們可以看到,客戶端代碼只需通過(guò)接口與適配器交互即可, 無(wú)需與具體的適配器類耦合。 這樣, 如果有需求我們就可以向程序中添加新類型的適配器而無(wú)需修改已有適配器實(shí)現(xiàn)。 這在我們的項(xiàng)目需要替換服務(wù)類的時(shí)候很有用,符合SOLID原則里的開閉原則。
我們先來(lái)看看用代碼怎么實(shí)現(xiàn)適配器模式,稍后再給大家演示一個(gè)實(shí)踐性更高的例子。
客戶端代碼直接通過(guò)適配器來(lái)間接使用被適配對(duì)象的功能,解決了兩者不兼容的問(wèn)題。
用適配器模式引入三方依賴
為什么建議引入依賴庫(kù)的時(shí)候使用適配器模式?項(xiàng)目使用第三方類庫(kù)的時(shí)候,防止未來(lái)有更換同等功能類庫(kù)的可能,一般會(huì)推薦使用適配器模式對(duì)三方類庫(kù)做一層封裝,這樣未來(lái)需要用同等功能的服務(wù)類進(jìn)行替換時(shí),實(shí)現(xiàn)一個(gè)新的適配器包裝服務(wù)類即可,不需要對(duì)已有的客戶端代碼進(jìn)行更改。
使用適配器模式,在項(xiàng)目中接入依賴庫(kù),這樣以后需要替換成其他同等功能的依賴庫(kù)的時(shí)候,不會(huì)影響到項(xiàng)目中的通過(guò)適配器使用依賴庫(kù)功能的代碼。
下面舉一個(gè)用適配器適配redigo庫(kù)為項(xiàng)目提供Redis Cache 功能的例子。
首先我們定義適配器接口,未來(lái)所有 Cache 類的適配器需要實(shí)現(xiàn)此接口。
這里為了簡(jiǎn)潔只定義了三個(gè)簡(jiǎn)單的存取Cache的方法,實(shí)際使用時(shí)我們可以把常用的Cache操作都定義成接口的方法。
定義適配器實(shí)現(xiàn)類, RedisCache 類型會(huì)Cache接口,同時(shí)我們?yōu)镽edisCache提供一個(gè)工廠方法,在工廠方法里進(jìn)行 Redis 鏈接池的初始化
接下來(lái)為RedisCache實(shí)現(xiàn) Cache 適配器接口的方法,這三個(gè)方法實(shí)現(xiàn)分別對(duì)應(yīng)Redis的 SET、GET和MGET操作。
客戶端在使用Cache時(shí),是直接用Cache接口中定義的方法跟適配器交互,由適配器再去轉(zhuǎn)換成對(duì)三方依賴庫(kù)redigo的調(diào)用完成Redis操作。
本文的完整源碼,已經(jīng)同步收錄到我整理的電子教程里啦,可向我的公眾號(hào)「網(wǎng)管叨bi叨」發(fā)送關(guān)鍵字【設(shè)計(jì)模式】領(lǐng)取。
公眾號(hào)「網(wǎng)管叨bi叨」發(fā)送關(guān)鍵字【設(shè)計(jì)模式】領(lǐng)取。
適配器和代理模式的區(qū)別
適配器模式和代理模式同屬于結(jié)構(gòu)型的設(shè)計(jì)模式,他們兩個(gè)在類結(jié)構(gòu)上也非常相似,都是由一個(gè)包裝對(duì)象持有原對(duì)象,把客戶端對(duì)包裝對(duì)象的請(qǐng)求轉(zhuǎn)發(fā)到原對(duì)象上。那么這兩個(gè)模式有什么不同呢?我們?cè)趺磪^(qū)分自己使用的是適配器還是代理模式?
適配器和代理模式的區(qū)別:
- 適配器與原對(duì)象(被適配對(duì)象)實(shí)現(xiàn)不同的接口,適配器的特點(diǎn)在于兼容,客戶端通過(guò)適配器的接口完成跟自己不兼容的原對(duì)象的訪問(wèn)交互。
- 代理與原對(duì)象(被代理對(duì)象)實(shí)現(xiàn)相同的接口,代理模式的特點(diǎn)在于隔離和控制,代理直接轉(zhuǎn)發(fā)原對(duì)象的返回給客戶端,但是可以在調(diào)用原始對(duì)象接口的前后做一些額外的輔助工作,AOP編程的實(shí)現(xiàn)也是利用這個(gè)原理。
總結(jié)
適配器模式的優(yōu)點(diǎn)是適配器類和原角色類解耦,提高程序的擴(kuò)展性。在很多業(yè)務(wù)場(chǎng)景中符合開閉原則。不改變?cè)薪涌?,卻還能使用新接口的功能。不過(guò)適配器的編寫過(guò)程需要結(jié)合業(yè)務(wù)場(chǎng)景全面考慮,同時(shí)也可能會(huì)增加系統(tǒng)的復(fù)雜性。
今天的文章就到這里啦,喜歡還請(qǐng)點(diǎn)個(gè)關(guān)注,每周更新最有實(shí)用性的編程知識(shí)。