我們來看一下適配器模式,我們先來看一下定義和類型,定義是將一個類的接口轉換成客戶期望的另一個接口,這里說的類的接口是被適配者,而另一個接口就是目標,目標類,使原本不兼容的類可以一起工作,類型是結構型,例如我們筆記本的電源適配器,或者手機的電源適配器,都是一個意思

適配器的應用場景,已經存在的類,他的方法和需求不匹配時,方法結果相同或者相似,這個基礎上如果出現這個場景,適配器為了復用現有的類,好多數據或行為,都正確,但是呢,接口不符合,這個時候就可以采取適配器模式,是原有對象和新接口匹配,那我們再看一下第二條,適配器模式不是軟件設計階段考慮的設計模式,是隨著軟件維護,由于不同產品,不同廠家,造成功能類似,而接口不相同情況下的解決方案,這個比較重要,也就是說如果我們去做一個新的項目,新的系統,那么在設計的時候,不要考慮適配器,適配器模式有點亡羊補牢的感覺,那設計階段盡量避免使用,但是隨著我們項目的不斷地發展,那這個時候就需要考慮適配器模式了

那我們看一下適配器模式的優點,能提高類的透明性,和復用,現有的類復用但不需要改變,解決現有類和目標類不匹配的問題,那第二條呢,目標類和適配器類解耦,提高程序的擴展性,那我們可以使用適配器模式,開發自己的功能,另外符合開閉原則,那具體的實現,都在適配器中,客戶端知道的只有適配器類,擴展的話只需要擴展適配器類就可以,而原有的類是不需要變化的,當然這里說的原則是指在某一個業務場景

那我們再看一下適配器的缺點,那適配器編寫過程需要全面考慮,可能會增加系統的復雜性,另外會增加系統代碼可讀的難度,如果過多的使用適配器,讓我們的系統非常的凌亂,不易整理,比如我們調用的是第一個接口,其實內部已經適配成了調用第二個接口的實現,那這種情況我們在讀代碼的時候,就很容易蒙圈,增加系統可讀的難度

那我們再看一下適配器的擴展,這里主要分對象適配器模式和類適配器模式,那對象適配器符合組合復用原則,并且使用委托機制,類適配器是使用類繼承來實現的

再看一下適配器相關的設計模式,那適配器模式和裝飾模式的對比,我們在裝飾模式里面,已經講了,我們講一下適配器模式和外觀模式,適配器和外觀都是對現有的類,系統的封裝,那外觀呢,定義了新的接口,而適配器是復用原有的接口,適配器是使原有的接口,協同工作,而外觀呢,則是在現在的接口中提供一個更方便的訪問入口,那我們如果強行的把外觀模式也稱之為適配的話,那這兩個最大的區別就在于適配的力度不同,那外觀模式呢是用來適配整個子系統,就是說相關的子系統,例如我們之前講的打開CPU,打開內存條,打開主板,打開硬盤等,所以外觀所針對的對象,力度更大

接下來我們會一起coding,會看一下UML,關于類適配器和對象適配器,再引入一個業務場景,然后看一下UML的演變過程,源碼分析會引著一起看一下JDK及Spring,SpringMVC,關于適配器模式的應用

?

總結

以上是生活随笔為你收集整理的适配器模式讲解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。