本文旨在討論抽象類和介面的作用、例項及使用場景，都是我的理解和總結。更多關於介面和抽象類的概念知識，可自行查閱相關文件。

1. 抽象類及其作用

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

在介紹面向物件概念時，我們知道類是客觀事物的抽象，而抽象類又是類的進一步抽象，該怎麼理解呢？

舉個例子，我們定義若干個類 class BMW、class Benz、class Audi，分別對客觀事物“寶馬”、“賓士”、“奧迪”三種汽車進行抽象，包含相關屬性和行為（即方法）。但是我們知道，汽車都有通用的屬性和行為，比如品牌、發動機、方向盤、輪胎等屬性，前進、後退、轉彎等行為，所以我們可以在寶馬、賓士等汽車之上，進一步抽象出“汽車”類 abstract class Car

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

2. 介面及其作用

下面我們來看看介面，假使我研發出來一臺會飛的汽車“伯特萊斯”（Bote-Royce），在程式中定義如下：

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

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

看起來沒問題：

• BoteRoyce extends Car：表達這是一輛汽車；
• fly() 方法：體現這車可以飛。

但是，隨著技術發展，出現了眾多可以製造飛行汽車的廠商，難道每一個可以飛的汽車都去定義一個 fly() 方法？

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

No No No... 正如不是所有牛奶都叫特侖蘇一樣，不是所有汽車都會飛，飛行功能不是汽車的通用特性。將 fly() 方法定義在 Car

在這種場景下，解決方案之一就是使用介面，如下：

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

類 BoteRoyce 的定義修改如下：

/*
 * 實現 Aircraft 介面，表示具備飛行器能力
 */
class BoteRoyce extends Car implements Aircraft {

    /**
     * 覆寫介面方法，實現飛行能力
     */
    @Override
    void fly() {
        System.out.println("假裝會飛~");
    }
}

再有其他品牌的飛行汽車，都可以通過 extends Car implements Aircraft 實現飛行能力。

上述定義的 interface Aircraft 即為介面，我們通常使用介面對行為進行抽象。

3. 介面和抽象類的區別

關於二者的區別，可以結合前面的例子，來加深理解。

抽象類是對類本質的抽象，表達的是 is a 的關係，比如：BMW is a Car。抽象類包含並實現子類的通用特性，將子類存在差異化的特性進行抽象，交由子類去實現。

而介面是對行為的抽象，表達的是 like a 的關係。比如：Bote-Royce like a Aircraft（像飛行器一樣可以飛），但其本質上 is a Car。介面的核心是定義行為，即實現類可以做什麼，至於實現類主體是誰、是如何實現的，介面並不關心。

4. 介面與抽象類的使用場景

熟悉 Java 的同學可能會質疑，上述關於介面的使用，完全可以通過再次抽象 Car 去實現：

/**
 * 會飛的汽車
 */
abstract class FlyCar extends Car {

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

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

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

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

如果你也這麼想，表示你 get 到了抽象類的點。不過話說回來，這樣的話介面豈不是沒有存在的意義了？

當然不是了。就 BoteRoyce 而言，如果你關心的是“飛行汽車”這個整體，那麼定義抽象類 FlyCar 是個不錯的選擇；如果你關心的是汽車具備“飛行”的行為，那不妨繼續沿用前面使用 Aircraft 介面的方案。

這一點與設計模式中六大原則之一的“里氏替換原則”不謀而合，該原則指出：所有引用基類（抽象類或介面）的地方必須能透明地使用其子類的物件。也就是說，當你遵循該原則時，你必須要考慮你關心的是“飛行汽車”實體，還是“飛行”行為，並將其作為基類，從而決定程式所能接受的子類物件。

同時，“介面隔離原則”指導我們，一個類對另一個類的依賴應該建立在最小的介面上。相比於抽象類 FlyCar，介面 Aircraft 能最大限度的減少對外暴露的介面，並隱藏細節，更符合這一原則。

所以說啊，面向物件只是指導我們程式設計的思想，而非條條框框。在實際開發中，具體使用抽象類還是介面，並沒有絕對限制，而是取決於你的業務場景和架構設計。