摘要：更多關(guān)于接口和抽象類的概念知識(shí)，可自行查閱相關(guān)文檔。抽象類及其作用抽象類，顧名思義，即類的抽象。而接口是對(duì)行為的抽象，表達(dá)的是的關(guān)系。相比于抽象類，接口能最大限度的減少對(duì)外暴露的接口，并隱藏細(xì)節(jié)，更符合這一原則。

作者：伯特
出處：github.com/ruicbAndroid/LoulanPlan
聲明：本文出自伯特的《樓蘭計(jì)劃》，轉(zhuǎn)載務(wù)必注明作者及出處。

本文旨在討論抽象類和接口的作用、實(shí)例及使用場(chǎng)景，都是我的理解和總結(jié)。更多關(guān)于接口和抽象類的概念知識(shí)，可自行查閱相關(guān)文檔。

抽象類，顧名思義，即類的抽象。

在介紹面向?qū)ο蟾拍顣r(shí)，我們知道類是客觀事物的抽象，而抽象類又是類的進(jìn)一步抽象，該怎么理解呢？

舉個(gè)例子，我們定義若干個(gè)類 class BMW、class Benz、class Audi，分別對(duì)客觀事物“寶馬”、“奔馳”、“奧迪”三種汽車進(jìn)行抽象，包含相關(guān)屬性和行為（即方法）。但是我們知道，汽車都有通用的屬性和行為，比如品牌、發(fā)動(dòng)機(jī)、方向盤、輪胎等屬性，前進(jìn)、后退、轉(zhuǎn)彎等行為，所以我們可以在寶馬、奔馳等汽車之上，進(jìn)一步抽象出“汽車”類 abstract class Car，包含通用的特性（屬性和方法）。讓 BMW、Benz、Audi 等繼承抽象類 extends Car，便擁有了汽車的通用特性，然后在抽象類基礎(chǔ)上定義各自的特殊屬性及方法。

這里的 abstract class Car 即抽象類，可以看出，抽象類是用來捕捉子類的通用特性的，包括屬性及行為。

下面我們來看看接口，假使我研發(fā)出來一臺(tái)會(huì)飛的汽車“伯特萊斯”（Bote-Royce），在程序中定義如下：

class BoteRoyce extends Car {
    //...省略通用特性

    /**
     * 可以飛
     */
    void fly() {
        System.out.println("假裝會(huì)飛~");
    }
}

看起來沒問題：

BoteRoyce extends Car：表達(dá)這是一輛汽車；

fly() 方法：體現(xiàn)這車可以飛。

但是，隨著技術(shù)發(fā)展，出現(xiàn)了眾多可以制造飛行汽車的廠商，難道每一個(gè)可以飛的汽車都去定義一個(gè) fly() 方法？

心想這還不簡(jiǎn)單，在抽象類 Car 中定義一個(gè)抽象方法 abstract void fly() 讓子類去實(shí)現(xiàn)，不就可以了嗎？

No No No... 正如不是所有牛奶都叫特侖蘇一樣，不是所有汽車都會(huì)飛，飛行功能不是汽車的通用特性。將 fly() 方法定義在 Car 中，顯然違背了“抽象類用來捕捉子類的通用特性”這一原則。

在這種場(chǎng)景下，解決方案之一就是使用接口，如下：

/**
 * 飛行器接口
 */
public interface Aircraft {
    //定義抽象方法
    void fly();
}

類 BoteRoyce 的定義修改如下：

/*
 * 實(shí)現(xiàn) Aircraft 接口，表示具備飛行器能力
 */
class BoteRoyce extends Car implements Aircraft {

    /**
     * 覆寫接口方法，實(shí)現(xiàn)飛行能力
     */
    @Override
    void fly() {
        System.out.println("假裝會(huì)飛~");
    }
}

再有其他品牌的飛行汽車，都可以通過 extends Car implements Aircraft 實(shí)現(xiàn)飛行能力。

上述定義的 interface Aircraft 即為接口，我們通常使用接口對(duì)行為進(jìn)行抽象。

關(guān)于二者的區(qū)別，可以結(jié)合前面的例子，來加深理解。

抽象類是對(duì)類本質(zhì)的抽象，表達(dá)的是 is a 的關(guān)系，比如：BMW is a Car。抽象類包含并實(shí)現(xiàn)子類的通用特性，將子類存在差異化的特性進(jìn)行抽象，交由子類去實(shí)現(xiàn)。

而接口是對(duì)行為的抽象，表達(dá)的是 like a 的關(guān)系。比如：Bote-Royce like a Aircraft（像飛行器一樣可以飛），但其本質(zhì)上 is a Car。接口的核心是定義行為，即實(shí)現(xiàn)類可以做什么，至于實(shí)現(xiàn)類主體是誰、是如何實(shí)現(xiàn)的，接口并不關(guān)心。

熟悉 Java 的同學(xué)可能會(huì)質(zhì)疑，上述關(guān)于接口的使用，完全可以通過再次抽象 Car 去實(shí)現(xiàn)：

/**
 * 會(huì)飛的汽車
 */
abstract class FlyCar extends Car {

    //定義抽象方法
    public abstract void fly();
}

普通的汽車依然 extends Car，可以飛行的汽車 extends FlyCar 即可：

/*
 * 繼承 FlyCar，表示是可以飛行的汽車
 */
class BoteRoyce extends FlyCar {

    /**
     * 覆寫抽象方法，實(shí)現(xiàn)飛行能力
     */
    @Override
    public void fly() {
        System.out.println("假裝會(huì)飛~");
    }
}

如果你也這么想，表示你 get 到了抽象類的點(diǎn)。不過話說回來，這樣的話接口豈不是沒有存在的意義了？

當(dāng)然不是了。就 BoteRoyce 而言，如果你關(guān)心的是“飛行汽車”這個(gè)整體，那么定義抽象類 FlyCar 是個(gè)不錯(cuò)的選擇；如果你關(guān)心的是汽車具備“飛行”的行為，那不妨繼續(xù)沿用前面使用 Aircraft 接口的方案。

這一點(diǎn)與設(shè)計(jì)模式中六大原則之一的“里氏替換原則”不謀而合，該原則指出：所有引用基類（抽象類或接口）的地方必須能透明地使用其子類的對(duì)象。也就是說，當(dāng)你遵循該原則時(shí)，你必須要考慮你關(guān)心的是“飛行汽車”實(shí)體，還是“飛行”行為，并將其作為基類，從而決定程序所能接受的子類對(duì)象。

同時(shí)，“接口隔離原則”指導(dǎo)我們，一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口上。相比于抽象類 FlyCar，接口 Aircraft 能最大限度的減少對(duì)外暴露的接口，并隱藏細(xì)節(jié)，更符合這一原則。

所以說啊，面向?qū)ο笾皇侵笇?dǎo)我們編程的思想，而非條條框框。在實(shí)際開發(fā)中，具體使用抽象類還是接口，并沒有絕對(duì)限制，而是取決于你的業(yè)務(wù)場(chǎng)景和架構(gòu)設(shè)計(jì)。

好了，本次關(guān)于接口與抽象類的總結(jié)就到這兒，你徹底弄懂了嗎？下期分享再見~

歡迎關(guān)注我的公眾號(hào)“伯特說”：