本分開始之前。咱先提出來幾個疑問：

• 介面有什麼用途？
• 面向介面程式設計的好處？
• 它和抽象類有什麼區別？
• 能不能用抽象類代替介面呢？
• 它和麵向物件程式設計是什麼關係？

本分主要分為：

• 1.面向介面程式設計和麵向物件程式設計是什麼關係？
• 2.介面本質
• 3.面向介面程式設計綜述
• 4.關於抽象類和介面
• 5.面向介面程式設計例項Demo
• 6.面向介面程式設計（Demo終極優化，擴充套件性超強，抽象工廠模式）

1.面向介面程式設計和麵向物件程式設計是什麼關係？

首先，面向介面程式設計和麵向物件程式設計並不是平級的，它也不是比面向物件程式設計更先進一步的一種獨立程式設計思想，而是附屬於面向物件程式設計的體系，屬於其中一部分，它是面向物件程式設計體系中的思想精髓之一。

2.介面本質

介面，在表面上是由幾個沒有主體程式碼的方法定義組成的集合體，有唯一的名稱，可以被類或其他介面所實現（或者也可以說繼承）。它在形式上可能是如下的樣子：

介面的特點：

• 介面中只能存放靜態常量和抽象方法;
• Java介面是對功能的擴充套件;
• 通過實現介面，java類可以實現多實現;
• 一個人可以同時繼承（extends）一個父類並且實現（implements）多個介面;
• 介面與介面之間可以通過使用extends來產生繼承關係;

介面與抽象類的區別

• 抽象類和具體實現類之間是一種繼承關係，也就是說如果採用抽象類的方式，則父類和子類在概念上應該是相同的;
• 介面和實現類在概念上不要求相同，介面只是抽取互相之間沒有關係的類的共同特徵，而不去關注類之間的關係，它可以使沒有層次關係的類具有相同的行為;
• 抽象類是對一組具有相同屬性和行為的邏輯上有關係的事物的一種抽象，而介面則是對一組具有相同屬性和行為的邏輯上不相關的事物的一種抽象;
• 對於介面和抽象類的選擇，反映出設計人員看待問題的不同角度。抽象類用於一組相關的事物，表示的事“is-a”的關係；而介面用於一組不相關的事物，表示的是“like-a”的關係;

interface InterfaceName
{
    void Method1();
    void Method2(int para1);
    void Method3(string para2,string para3);
}

• 1）介面是一組規則的集合，它規定了實現本介面的類或介面必須擁有的一組規則。體現了自然界“如果你是……則必須能……”的理念。

例如：
在自然界中，人都能吃飯，即“如果你是人，則必須能吃飯”。那麼模擬到計算機程式中，就應該有一個IPerson（習慣上，介面名由“I”開頭）介面，並有一個方法叫Eat()，然後我們規定，每一個表示“人”的類，必須實現IPerson介面，這就模擬了自然界“如果你是人，則必須能吃飯”這條規則。

從這裡，我想各位也能看到些許面向物件思想的東西。面向物件思想的核心之一，就是模擬真實世界，把真實世界中的事物抽象成類，整個程式靠各個類的例項互相通訊、互相協作完成系統功能，這非常符合真實世界的執行狀況，也是面向物件思想的精髓。

• 2）介面是在一定粒度檢視上同類事物的抽象表示。注意這裡我強調了在一定粒度檢視上，因為“同類事物”這個概念是相對的，它因為粒度檢視不同而不同。

例如：
在我的眼裡，我是一個人，和一頭豬有本質區別，我可以接受我和我同學是同類這個說法，但絕不能接受我和一頭豬是同類。但是，如果在一個動物學家眼裡，我和豬應該是同類，因為我們都是動物，他可以認為“人”和“豬”都實現了IAnimal這個介面，而他在研究動物行為時，不會把我和豬分開對待，而會從“動物”這個較大的粒度上研究，但他會認為我和一棵樹有本質區別。

現在換了一個遺傳學家，情況又不同了，因為生物都能遺傳，所以在他眼裡，我不僅和豬沒區別，和一隻蚊子、一個細菌、一顆樹、一個蘑菇乃至一個SARS病毒都沒什麼區別，因為他會認為我們都實現了IDescendable這個介面（注：descend vi. 遺傳），即我們都是可遺傳的東西，他不會分別研究我們，而會將所有生物作為同類進行研究，在他眼裡沒有人和病毒之分，只有可遺傳的物質和不可遺傳的物質。但至少，我和一塊石頭還是有區別的。

可不幸的事情發生了，某日，地球上出現了一位偉大的人，他叫列寧，他在熟讀馬克思、恩格斯的辯證唯物主義思想鉅著後，頗有心得，於是他下了一個著名的定義：所謂物質，就是能被意識所反映的客觀實在。至此，我和一塊石頭、一絲空氣、一條成語和傳輸手機訊號的電磁場已經沒什麼區別了，因為在列寧的眼裡，我們都是可以被意識所反映的客觀實在。如果列寧是一名程式設計師，他會這麼說：所謂物質，就是所有同時實現了“IReflectabe”和“IEsse”兩個介面的類所生成的例項。（注：reflect v. 反映 esse n. 客觀實在）

也許你會覺得我上面的例子像在瞎掰，但是，這正是介面得以存在的意義。面向物件思想和核心之一叫做多型性，什麼叫多型性？說白了就是在某個粒度檢視層面上對同類事物不加區別的對待而統一處理。而之所以敢這樣做，就是因為有介面的存在。像那個遺傳學家，他明白所有生物都實現了IDescendable介面，那隻要是生物，一定有Descend（）這個方法，於是他就可以統一研究，而不至於分別研究每一種生物而最終累死。

可能這裡還不能給你一個關於介面本質和作用的直觀印象。那麼在後文的例子和對幾個設計模式的解析中，你將會更直觀體驗到介面的內涵。

3.面向介面程式設計綜述

通過上文，我想大家對介面和介面的思想內涵有了一個瞭解。

1）問題一：那麼什麼是面向介面程式設計呢？
我個人的定義是：在系統分析和架構中，分清層次和依賴關係，每個層次不是直接向其上層提供服務（即不是直接例項化在上層中），而是通過定義一組介面，僅向上層暴露其介面功能，上層對於下層僅僅是介面依賴，而不依賴具體類。

2）問題二：使用面向介面程式設計好處？
首先對系統靈活性大有好處。當下層需要改變時，只要介面及介面功能不變，則上層不用做任何修改。甚至可以在不改動上層程式碼時將下層整個替換掉，就像我們將一個WD的60G硬碟換成一個希捷的160G的硬碟，計算機其他地方不用做任何改動，而是把原硬碟拔下來、新硬碟插上就行了，因為計算機其他部分不依賴具體硬碟，而只依賴一個IDE介面，只要硬碟實現了這個介面，就可以替換上去。從這裡看，程式中的介面和現實中的介面極為相似，所以我一直認為，介面（interface）這個詞用的真是神似！

使用介面的另一個好處就是不同部件或層次的開發人員可以並行開工，就像造硬碟的不用等造CPU的，也不用等造顯示器的，只要介面一致，設計合理，完全可以並行進行開發，從而提高效率。

4.關於抽象類和介面

如果單從具體程式碼來看，對這兩個概念很容易模糊，甚至覺得介面就是多餘的，因為單從具體功能來看，除多重繼承外（C#，Java中），抽象類似乎完全能取代介面。但是，難道介面的存在是為了實現多重繼承？當然不是。我認為，抽象類和介面的區別在於使用動機。使用抽象類是為了程式碼的複用，而使用介面的動機是為了實現多型性。所以，如果你在為某個地方該使用介面還是抽象類而猶豫不決時，那麼可以想想你的動機是什麼。

看到有朋友對IPerson這個介面的質疑，我個人的理解是，IPerson這個介面該不該定義，關鍵看具體應用中是怎麼個情況。如果我們的專案中有Women和Man，都繼承Person，而且Women和Man絕大多數方法都相同，只有一個方法DoSomethingInWC（）不同（例子比較粗俗，各位見諒），那麼當然定義一個AbstractPerson抽象類比較合理，因為它可以把其他所有方法都包含進去，子類只定義DoSomethingInWC（），大大減少了重複程式碼量。

但是，如果我們程式中的Women和Man兩個類基本沒有共同程式碼，而且有一個PersonHandle類需要例項化他們，並且不希望知道他們是男是女，而只需把他們當作人看待，並實現多型，那麼定義成介面就有必要了。

總而言之，介面與抽象類的區別主要在於使用的動機，而不在於其本身。而一個東西該定義成抽象類還是介面，要根據具體環境的上下文決定。

再者，我認為介面和抽象類的另一個區別在於，抽象類和它的子類之間應該是一般和特殊的關係，而介面僅僅是它的子類應該實現的一組規則。（當然，有時也可能存在一般與特殊的關係，但我們使用介面的目的不在這裡）如，交通工具定義成抽象類，汽車、飛機、輪船定義成子類，是可以接受的，因為汽車、飛機、輪船都是一種特殊的交通工具。再譬如Icomparable介面，它只是說，實現這個介面的類必須要可以進行比較，這是一條規則。如果Car這個類實現了Icomparable，只是說，我們的Car中有一個方法可以對兩個Car的例項進行比較，可能是比哪輛車更貴，也可能比哪輛車更大，這都無所謂，但我們不能說“汽車是一種特殊的可以比較”，這在文法上都不通。

5.面向介面程式設計例項Demo

• Demo問題的提出：

定義：現在我們要開發一個應用，模擬移動儲存裝置的讀寫，即計算機與U盤、MP3、行動硬碟等裝置進行資料交換。

上下文（環境）：已知要實現U盤、MP3播放器、行動硬碟三種移動儲存裝置，要求計算機能同這三種裝置進行資料交換，並且以後可能會有新的第三方的移動儲存裝置，所以計算機必須有擴充套件性，能與目前未知而以後可能會出現的儲存裝置進行資料交換。各個儲存裝置間讀、寫的實現方法不同，U盤和行動硬碟只有這兩個方法，MP3Player還有一個PlayMusic方法。

名詞定義：資料交換={讀，寫}

看到上面的問題，我想各位腦子中一定有了不少想法，這是個很好解決的問題，很多方案都能達到效果。下面，我列舉幾個典型的方案。

• 解決方案列舉

方案一：分別定義UDisk、MP3Player、MobileHardDisk三個類，實現各自的Read和Write方法。然後在Computer類中例項化上述三個類，為每個類分別寫讀、寫方法。例如，為UDisk寫read、write。總共六個方法。

方案二：定義抽象類MobileStorage，在裡面寫虛方法Read和Write，三個儲存裝置繼承此抽象類，並重寫read和write方法。Computer類中包含一個型別為MobileStorage的成員變數，併為其編寫get/set器，這樣Computer中只需要兩個方法：readData和writeData，並通過多型性實現不同移動裝置的讀寫。

方案三：與方案二基本相同，只是不定義抽象類，而是定義介面IMobileStorage，移動儲存器類實現此介面。Computer中通過依賴介面IMobileStorage實現多型性。

方案四：定義介面IReadable和IWritable，兩個介面分別只包含read和write，然後定義介面IMobileStorage介面繼承自IReadable和IWritable，剩下的實現與方案三相同。

• 分析上面四種方案：

首先，方案一最直白，實現起來最簡單，但是它有一個致命的弱點：可擴充套件性差。或者說，不符合“開放-關閉原則”（注：意為對擴充套件開放，對修改關閉）。當將來有了第三方擴充套件移動儲存裝置時，必須對Computer進行修改。這就如在一個真實的計算機上，為每一種移動儲存裝置實現一個不同的插口、並分別有各自的驅動程式。當有了一種新的移動儲存裝置後，我們就要將計算機大卸八塊，然後增加一個新的插口，在編寫一套針對此新裝置的驅動程式。這種設計顯然不可取。

此方案的另一個缺點在於，冗餘程式碼多。如果有100種移動儲存，那我們的Computer中豈不是要至少寫200個方法，這是不能接受的！

我們再來看方案二和方案三，之所以將這兩個方案放在一起討論，是因為他們基本是一個方案（從思想層面上來說），只不過實現手段不同，一個是使用了抽象類，一個是使用了介面，而且最終達到的目的應該是一樣的。

我們先來評價這種方案：首先它解決了程式碼冗餘的問題，因為可以動態替換移動裝置，並且都實現了共同的介面，所以不管有多少種移動裝置，只要一個Read方法和一個Write方法，多型性就幫我們解決問題了。而對第一個問題，由於可以執行時動態替換，而不必將移動儲存類硬編碼在Computer中，所以有了新的第三方裝置，完全可以替換進去執行。這就是所謂的“依賴介面，而不是依賴與具體類”，不信你看看，Computer類只有一個MobileStorage型別或IMobileStorage型別的成員變數，至於這個變數具體是什麼型別，它並不知道，這取決於我們在執行時給這個變數的賦值。如此一來，Computer和移動儲存器類的耦合度大大下降。

那麼這裡該選抽象類還是介面呢？還記得第一篇文章我對抽象類和介面選擇的建議嗎？看動機。這裡，我們的動機顯然是實現多型性而不是為了程式碼複用，所以當然要用介面。

最後我們再來看一看方案四，它和方案三很類似，只是將“可讀”和“可寫”兩個規則分別抽象成了介面，然後讓IMobileStorage再繼承它們。這樣做，顯然進一步提高了靈活性，但是，這有沒有設計過度的嫌疑呢？我的觀點是：這要看具體情況。如果我們的應用中可能會出現一些類，這些類只實現讀方法或只實現寫方法，如只讀光碟，那麼這樣做也是可以的。如果我們知道以後出現的東西都是能讀又能寫的，那這兩個介面就沒有必要了。其實如果將只讀裝置的Write方法留空或丟擲異常，也可以不要這兩個介面。總之一句話：理論是死的，人是活的，一切從現實需要來，防止設計不足，也要防止設計過度。

在這裡，我們姑且認為以後的移動儲存都是能讀又能寫的，所以我們選方案三。

• 實現
  下面，我們要將解決方案加以實現。我選擇的語言java，使用其他語言的朋友一樣可以參考。

(1)介面

首先編寫IMobileStorage介面：

public interface IMobileStorage {
    void read();//讀資料

    void write();//寫資料
}

程式碼比較簡單，只有兩個方法
(2)U盤

public class UDisk implements IMobileStorage {
    @Override
    public void read() {
        ToastUtils.getInstance().showToast(OKApplication.context,"UDisk,正在讀取資料\n UDisk,讀取資料完畢\"");
    }

    @Override
    public void write() {
        ToastUtils.getInstance().showToast(OKApplication.context,"UDisk,正在寫入資料\n UDisk,讀取寫入完畢\"");
    }
}

(3)MP3

public class Mp3 implements IMobileStorage{
    @Override
    public void read() {
        ToastUtils.getInstance().showToast(OKApplication.context,"Mp3,正在讀取資料\n Mp3,讀取資料完畢\"");
    }

    @Override
    public void write() {
        ToastUtils.getInstance().showToast(OKApplication.context,"Mp3,正在寫入資料\n Mp3,讀取寫入完畢\"");
    }

    @Override
    public void playMusic() {
        ToastUtils.getInstance().showToast(OKApplication.context,"Mp3,開始播放音樂");
    }
}

(4)行動硬碟

public class MobileHardDisk implements IMobileStorage {
    @Override
    public void read() {
        ToastUtils.getInstance().showToast(OKApplication.context,"MobileHardDisk,正在讀取資料\n MobileHardDisk,讀取資料完畢\"");
    }

    @Override
    public void write() {
        ToastUtils.getInstance().showToast(OKApplication.context,"MobileHardDisk,正在寫入資料\n MobileHardDisk,讀取寫入完畢\"");
    }
}

可以看到，它們都實現了IMobileStorage介面，並重寫了各自不同的Read和Write方法。下面，我們來寫Computer：
(5)computer

public class Computer {
    private IMobileStorage iMobileStorage;

    public Computer() {
    }

    public IMobileStorage getiMobileStorage() {
        return iMobileStorage;
    }

    public void setiMobileStorage(IMobileStorage iMobileStorage) {
        this.iMobileStorage = iMobileStorage;
    }

    public void readData() {
        this.iMobileStorage.read();
    }

    public void writeData() {
        this.iMobileStorage.write();
    }
}

(6)具體程式碼

        tvSend1.setOnClickListener(v -> {
            computer.setiMobileStorage(new Mp3());
            computer.readData();
            computer.writeData();
        });
        tvSend3.setOnClickListener(v -> {
            computer.setiMobileStorage(new UDisk());
            computer.readData();
            computer.writeData();
        });
        tvSend4.setOnClickListener(v -> {
            computer.setiMobileStorage(new MobileHardDisk());
            computer.readData();
            computer.writeData();
        });

(7)加入新裝置
後來……
　　剛過了一個星期，就有人送來了新的移動儲存裝置NewMobileStorage，讓我測試能不能用，我微微一笑，心想這不是小菜一碟，讓我們看看面向介面程式設計的威力吧！將測試程式修改成如下：
　　

        tvSend5.setOnClickListener(v -> {
            computer.setiMobileStorage(new NewMobileStorage());
            computer.readData();
            computer.writeData();
        });

(8)新裝置，不適配。自己新增介面卡

又過了幾天，有人通知我說又有一個叫SuperStorage的移動裝置要接到我們的Computer上，我心想來吧，管你是“超級儲存”還是“特級儲存”，我的“面向介面程式設計大法”把你們統統搞定。

　　但是，當裝置真的送來，我傻眼了，開發這個新裝置的團隊沒有拿到我們的IMobileStorage介面，自然也沒有遵照這個約定。這個裝置的讀、寫方法不叫Read和Write，而是叫rd和wt，這下完了……不符合介面啊，插不上。但是，不要著急，我們回到現實來找找解決的辦法。我們一起想想：如果你的Computer上只有USB介面，而有人拿來一個PS/2的滑鼠要插上用，你該怎麼辦？想起來了吧，是不是有一種叫“PS/2-USB”轉換器的東西？也叫介面卡，可以進行不同介面的轉換。對了！程式中也有轉換器。
　　
　　介面卡程式碼如下：

public class SuperStorageAdapter {

    private ISuperStorage iSuperStorage;

    public SuperStorageAdapter() {
    }

    public ISuperStorage getSuperStorage() {
        return iSuperStorage;
    }

    public void setSuperStorage(ISuperStorage iSuperStorage) {
        this.iSuperStorage = iSuperStorage;
    }

    public void readData() {
        this.iSuperStorage.rd();
    }

    public void writeData() {
        this.iSuperStorage.wt();
    }
}

tvSend6.setOnClickListener(v -> {
            //適配新裝置
            SuperStorageAdapter superStorageAdapter = new SuperStorageAdapter();
            SuperStorage superStorage = new SuperStorage();
            superStorageAdapter.setSuperStorage(superStorage);
            superStorageAdapter.readData();
            superStorageAdapter.writeData();
        });

6.面向介面程式設計（Demo終極優化，擴充套件性超強，抽象工廠模式）

寫到這裡是不是感覺面向介面程式設計講完了，但是你們有沒有發現，Mp3類有個自己的方法，playMusic（），難道需要用Mp3的物件去呼叫嗎？這不是又違背了面向介面程式設計的理念了？

於是，想了想，是不是可以在寫一個IMobileMusic介面，有一個playMusic的方法，在Mp3類同時也實現IMobileMusic，然後再Computer在加入一個IMobileMusic的成員變數不就可以了嗎？

想想好像可以，可是這樣擴張性如何呢？假如以後又多了個看視訊的功能，就需要不斷的對Computer進行修改。擴充套件性就會特別差。而且U盤或者行動硬碟沒有playMusic，卻可以呼叫，這也是不合理的地方。

今天上班偷了個小懶，來寫寫demo，於是找來了同時討論了一番，最終想到了一個設計模式，抽象工廠模式。至於這種模式，大家可以百度檢視一下，我就不在這裡講解了。

首先，先上一個這個demo的流程圖，純手畫，輕點吐槽：

下面加入抽象工廠模式優化下程式碼

• （1）IMobileMusic音樂播放的介面：

public interface IMobileMusic {

    void playMusic();

    void stopMusic();
}

此時Mp3變為了：

public class Mp3 implements IMobileStorage,IMobileMusic {
    @Override
    public void read() {
        ToastUtils.getInstance().showToast(OKApplication.context,"Mp3,正在讀取資料\n Mp3,讀取資料完畢\"");
    }

    @Override
    public void write() {
        ToastUtils.getInstance().showToast(OKApplication.context,"Mp3,正在寫入資料\n Mp3,讀取寫入完畢\"");
    }

    @Override
    public void playMusic() {
        ToastUtils.getInstance().showToast(OKApplication.context,"Mp3,開始播放音樂");
    }

    @Override
    public void stopMusic() {
        ToastUtils.getInstance().showToast(OKApplication.context,"Mp3,停止播放音樂");
    }
}

• （2）音樂的抽象工廠類：

public abstract class FactoryMusic<T> {
    //音樂
    public abstract T getMobileMusic();
}

• （3）抽象工廠的具體實現類：

public class ConcreteFactioryMusic extends FactoryMusic {

    private IMobileMusic iMobileMusic;

    public ConcreteFactioryMusic() {
    }

    public ConcreteFactioryMusic(IMobileMusic iMobileMusic) {
        this.iMobileMusic = iMobileMusic;
    }

    public IMobileMusic getiMobileMusic() {
        return iMobileMusic;
    }

    public void setiMobileMusic(IMobileMusic iMobileMusic) {
        this.iMobileMusic = iMobileMusic;
    }

    @Override
    public IMobileMusic getMobileMusic() {
        return this.iMobileMusic;
    }
}

• （4）Mp3程式碼的具體呼叫部分

        tvSend2.setOnClickListener(v -> {
            //使用抽象工廠模式
            FactoryMusic music = new ConcreteFactioryMusic(new Mp3());
            FactoryStorage storage = new ConcreteFactoryStorage(new Mp3());
            IMobileMusic iMobileMusic = (IMobileMusic) music.getMobileMusic();
            IMobileStorage iMobileStorage = (IMobileStorage) storage.getMobileStrage();
            iMobileStorage.read();
            iMobileStorage.write();
            iMobileMusic.playMusic();
            iMobileMusic.stopMusic();
        });

• （5）同理，對於來了一個新裝置，使用的還是rd，wt的讀寫，需要適配的話

那麼對於這種情況，我們還需要重寫一個適配的抽象工廠的具體實現。

ConcreteFactorageStorageAdapter 類，實現抽象工廠FactoryStorage ：

/**
 * 適配用的（新的裝置）
 * Created by zxp on 2016/6/27.
 */
public class ConcreteFactorageStorageAdapter extends FactoryStorage {

    private ISuperStorage iSuperStorage;

    public ConcreteFactorageStorageAdapter() {
    }

    public ConcreteFactorageStorageAdapter(ISuperStorage iSuperStorage) {
        this.iSuperStorage = iSuperStorage;
    }

    public ISuperStorage getiSuperStorage() {
        return iSuperStorage;
    }

    public void setiSuperStorage(ISuperStorage iSuperStorage) {
        this.iSuperStorage = iSuperStorage;
    }

    @Override
    public ISuperStorage getMobileStrage() {
        return iSuperStorage;
    }
}

具體的程式碼呼叫：

        tvSend7.setOnClickListener(v -> {
            //適配新裝置,抽象工廠模式
            FactoryStorage factoryStorage = new ConcreteFactorageStorageAdapter(new SuperStorage());
            ISuperStorage iSuperStorage = (ISuperStorage) factoryStorage.getMobileStrage();
            SuperStorageAdapter superStorageAdapter = new SuperStorageAdapter();
            superStorageAdapter.setSuperStorage(iSuperStorage);
            superStorageAdapter.readData();
            superStorageAdapter.writeData();
        });

那麼到此，具體的都寫完了。。。有些類沒有貼出來，請檢視Demo地址(github)的InterfaceExampleFragment類，瀏覽具體的實現。