設計模式之適配器模式

適配器模式.png

這是我參與8月更文挑戰的第6天,活動詳情查看:8月更文挑戰java

歡迎來到今天的學習,今天咱們一塊兒來學習下使用頻率不是很高的可是極易搞懂的一種模式----適配器模式。多嘮叨幾句,我本月將會對java的設計模式精講,歡迎點擊頭像,關注個人專欄,我會持續更新,加油!程序員

系列文章:設計模式

設計模式之單例模式markdown

設計模式之工廠模式網絡

設計模式之建造者模式app

設計模式之代理模式ide

設計模式之訪問者模式post

...持續更新中學習

話很少說,進入正題this

適配器模式

顧名思義,該模式確定是爲了爲兼容而生的。適配兩個原本不兼容的事物,能夠將二者友好相處,協同工做。

該模式的原始定義爲:將類的接口轉換爲客戶指望的另外一個接口,適配器可讓不兼容的兩個類一塊兒協同工做。

注意:該定義中明確說明了適配器模式的關鍵點就在於轉換而轉換時要在已有的接口基礎上作好兼容。

咱們也能夠拿生活當中的例子更加形象的解釋。好比咱們開會時用的投影儀,本電腦開放出來的接口,和大屏上的接口不兼容,這時候須要一箇中間的適配器來轉換下。

咱們程序員通常都須要分屏,一個寫代碼,一個看文檔,一個查資料,將三個屏幕鏈接在一塊兒不必定全部的接口就適用。像本人的mac電腦就不兼容,mac電腦上只開放了mac的扁形接口。還得本身買個適配器(該適配器開放了vga,HDMI,網絡線插口),那麼這個適配器,起到了無可替代的做用(下圖便是適配器,也叫擴展器)

image.png

根據類圖拆分講解

適配器模式的通用類圖以下:

image.png

從改圖能夠看到三個關鍵角色(也就是圖中黃色部分)

  • 目標類, 用戶期待的鏈接口,適配器類即將要進行適配的抽象類或接口;

  • 適配器類, 能夠是類或接口,是做爲具體適配者類的中間類來使用;

  • 具體適配者類, 能夠是內部的類或服務,也能夠是外部對象或服務。

其實不難發現,適配器模式封裝了三個重要事實

  • 具體適配者類能夠有不一樣的接口

  • 用戶在使用適配器類時實際上使用了多個接口;

  • 適配器類和具體適配者類引入了變化。

以下簡圖所示,適配器模式的類其實是做爲中間者來封裝變化的。

image.png

下面咱們根據實際代碼來深刻理解下

代碼展現

場景:拿咱們程序員用mac鏈接一個分屏的場景,根據咱們上面所說的類圖和講解來寫下代碼(必定要看註釋)

//建立Target接口
public interface Target {
    //這是源類Adapteee沒有的方法
    public void Request(); 
}


//建立源類(Adaptee)
public class Adaptee {
    
    public void SpecificRequest(){
    }
}


//建立適配器類(Adapter)
//適配器Adapter繼承自Adaptee,同時又實現了目標(Target)接口。
public class Adapter extends Adaptee implements Target {

    //目標接口要求調用Request()這個方法名,但源類Adaptee沒有方法Request()
    //所以適配器補充上這個方法名
    //但實際上Request()只是調用源類Adaptee的SpecificRequest()方法的內容
    @Override
    public void Request() {
    
        //重要:
        //適配器只是將SpecificRequest()方法做了一層封裝,封裝成Target能夠調用的Request()而已
        //這裏就是兼容,就是轉換,把咱們蘋果電腦的接口利用適配器(擴展器)鏈接到了分屏上
        this.SpecificRequest();
    }
}
複製代碼

接下來,定義具體使用目標類,並經過Adapter類調用所須要的方法從而實現目標

public class AdapterPattern {

    public static void main(String[] args){
        Target mAdapter = new Adapter();
        //看似調用request. 實際上是SpecificRequest,
        mAdapter.Request();
    }
}
複製代碼

這就是適配器模式。將一個類的接口變換成客戶端所期待的另外一個接口,從而是本來由於接口不匹配而沒法在一塊兒工做的兩個類可以在一塊兒工做。

總結

我的認爲當你碰到如下幾種狀況的時候可使用該模式:

  • 原有接口沒法修改時

  • 適配不一樣數據格式時

  • 須要過渡升級舊接口時(好比app升級須要一個審覈期,可是後臺代碼一會兒就更新了)

適配器模式優勢我認爲仍是不少的,而後獲得也就意味要犧牲一些。全部的模式都同樣

優勢:

  • 解耦:將目標類和適配者類解耦,經過引入一個適配器類重用現有的適配者類,而無需修改原有代碼

  • 擴展性強: 在實現適配器功能的時候,能夠調用本身開發的功能,任意擴展

  • 符合開放-關閉原則:同一個適配器能夠把適配者類和它的子類都適配到目標接口;能夠爲不一樣的目標接口實現不一樣的適配器,而不須要修改待適配類

缺點嘛:我認爲有如下幾點:

一、若是適配器使用太多,會致使臃腫,總體系統會很是凌亂。

二、修改目標接口會致使全部適配接口都須要定製修改

三、一次只能適配一個抽象類或接口(由於java是單繼承,多實現);

弦外之音

OK 今天的適配器就講到這裏,感謝你的閱讀,若是你感受學到了東西,麻煩您點贊,關注。

我已經將本章收錄在專題裏,點擊下方專題,關注專欄,我會天天發表乾貨,本月我會持續輸入設計模式。

加油! 咱們下期再見

相關文章
相關標籤/搜索