我們都知道應該面向介面程式設計。介面給定使用者應該使用的協議，而不用依賴該介面的具體實現細節。

因此，為了做到鬆耦合，設計出乾淨的介面成為API設計的要素之一。SOLID五大原則之一的要求我們設計有具體目的的小介面，而不是一個通用卻臃腫的介面。對你的類庫和應用來說，介面設計是能否得到乾淨而高效的API的關鍵。

這一節的程式碼在ch01包中

如果你曾經設計過API，隨著時間的推移，你可能覺得有必要在API中新增新的方法。一旦API已經發布，想要在不破壞已有實現的前提下對一個介面新增方法會變得非常困難。為了說清這一點，假設你正在構建一個簡單的能夠支援加、減、乘、除操作的計算器API。我們可以寫一個Calculator

public interface Calculator {

    int add(int first, int second);

    int subtract(int first, int second);

    int divide(int number, int divisor);

    int multiply(int first, int second);
}

回到這個Caculator介面，你建立了一個BasicCaculator的實現類，如下所示。

public class BasicCalculator
 
 implements Calculator {

    @Override
    public int add(int first, int second) {
        return first + second;
    }

    @Override
    public int subtract(int first, int second) {
        return first - second;
    }

    @Override
    public int divide(int number, int divisor) {
        if (divisor == 0
 
) {
            throw new IllegalArgumentException("divisor can't be zero.");
        }
        return number / divisor;
    }

    @Override
    public int multiply(int first, int second) {
        return first * second;
    }
}

靜態工廠方法

假設這個計算器API非常有用也容易上手。使用者只需要自己建立一個BasicCalculator的例項，就能夠使用該API。你可以看到如下的程式碼。

Calculator calculator = new BasicCalculator();
int sum = calculator.add(1, 2);

BasicCalculator cal = new BasicCalculator();
int difference = cal.subtract(3, 2);

然而有些使用者沒有面向介面Caculator進行程式設計，相反，他們面向該介面的 實現類BasicCalculator進行程式設計。你的API沒有強制使用者面向介面程式設計，因為BasicCalculator是public的。如果你將BasicCalculator宣告為protected，那麼你需要建立一個能夠提供Calculator實現類的靜態工廠。我們通過優化程式碼來解決這個問題。

首先，我們將BasicCalculator宣告為protected以便使用者不能夠直接使用該類。

class BasicCalculator implements Calculator {
  // rest remains same
}

接著，我們編寫一個能夠給我提供Calculator例項的工廠類，如下所示。

public abstract class CalculatorFactory {

    public static Calculator getInstance() {
        return new BasicCalculator();
    }
}

現在，使用者會被迫面向Calculator介面進行程式設計，而且他們不能夠知道該介面具體的實現細節。

雖然我們實現了我們的目的，但我們新增的新類CaculatorFactory也增加了API的複雜度。現在API的使用者在使用API之前需要多瞭解一個類。這是在該問題在Java8之前唯一的解決方案。

Java8允許在介面中定義靜態方法。這允許API設計者在介面中定義像getInstance一樣的靜態工具方法，這樣就能夠使得API簡潔而精練。在介面中的靜態方法能夠用來代替輔助類（像CalculatorFactory），通常我們建立這些輔助類來定義一些與特定型別相關的輔助方法。舉例來說，Collections類就是一個定義了眾多輔助方法來與集合和其相關介面進行協作的輔助類。在Collections中定義的方法能夠輕易的新增到Collection介面或者它的子介面中。

以上的程式碼在Java8中可以通過新增在Calculator介面中新增一個getInstance方法來改進。

public interface Calculator {

    static Calculator getInstance() {
        return new BasicCalculator();
    }

    int add(int first, int second);

    int subtract(int first, int second);

    int divide(int number, int divisor);

    int multiply(int first, int second);

}

與時俱進地優化API

有些使用者可能決定通過新增像remainder這樣的方法，或者為Calculator介面給出他們自己的實現來擴充套件CalculatorAPI。通過與使用者的溝通後，你發現大多數使用者想要在Calculator介面中新增一個remainder方法。這看起來是一個非常簡單的API變動，所以你在API中多添加了一個方法。

public interface Calculator {

    static Calculator getInstance() {
        return new BasicCalculator();
    }

    int add(int first, int second);

    int subtract(int first, int second);

    int divide(int number, int divisor);

    int multiply(int first, int second);

    int remainder(int number, int divisor); // new method added to API
}

在介面中新增方法破壞了API的原始碼相容性。這意味著實現了Calculator介面的使用者需要新增remainder方法的實現，否則他們的程式碼將不能通過編譯。這對於API開發者來說是一個大問題，這使得API很難進行改進。在Java8之前，介面中是不能有方法的具體實現的。這往往在API需要拓展的時候成為一個問題，比如在介面定義中新增一兩個方法。

為了使API隨著時間的推移能夠不斷改進，Java8允許使用者在介面中給方法提供預設實現。這些方法被稱為default方法，或者defender方法。實現了該介面的類不需要給這些方法提供實現。如果一個實現類為這些方法提供了實現，那麼新給出的實現將會被使用，否則介面中的預設實現將被使用。List介面定義了一些default方法，像replaceAll、sort和splitIterator。

default void replaceAll(UnaryOperator<E> operator) {
    Objects.requireNonNull(operator);
    final ListIterator<E> li = this.listIterator();
    while (li.hasNext()) {
        li.set(operator.apply(li.next()));
    }
}

如下面的程式碼所示，我們可以通過新增一個default方法來解決上述的API問題。default方法通常使用已經存在的方法進行定義，如remainder方法使用了subtract、multiply和divide方法。

default int remainder(int number, int divisor) {
    return subtract(number, multiply(divisor, divide(number, divisor)));
}

多重繼承

Java中一個類只能繼承一個類，但可以實現多個介面。現在在介面中包含方法的實現是可行的，Java也就有了類似多重繼承的特性。Java在型別層面已經存在多重繼承特性，現在在行為層面也有了多重繼承特性。有三條規則來幫助決定哪一個方法會被選中。

規則1：在類中定義的方法勝過在介面中定義的方法

interface A {
    default void doSth(){
        System.out.println("inside A");
    }
}
class App implements A{

    @Override
    public void doSth() {
        System.out.println("inside App");
    }

    public static void main(String[] args) {
        new App().doSth();
    }
}

這將打印出inside App，因為在實現類中已經覆蓋了介面中定義的方法。

規則2：明確的介面勝過上層介面

interface A {
    default void doSth() {
        System.out.println("inside A");
    }
}
interface B {}
interface C extends A {
    default void doSth() {
        System.out.println("inside C");
    }
}
class App implements C, B, A {

    public static void main(String[] args) {
        new App().doSth();
    }
}

這將打印出inside C。

規則3：執行在類中明確指明的實現方式

interface A {
    default void doSth() {
        System.out.println("inside A");
    }
}
interface B {
    default void doSth() {
        System.out.println("inside B");
    }
}
class App implements B, A {

    @Override
    public void doSth() {
        B.super.doSth();
    }

    public static void main(String[] args) {
      new App().doSth();
    }
}

這將會打印出inside B。