在物件導向程式設計當中，抽象類和介面是為抽象而生而的兩個概念，在初學時特別容易搞混它們倆。
Java 既支援介面，也支援抽象類，這裡主要拿 Java 的介面和抽象類做比較。簡單地在 Java 中定義這兩個概念就是，抽象類是包含抽象方法的類，介面是對行為的抽象。
在 Java 中，抽象類仍然以 class 定義，並在此基礎上增加 abstract 修飾，如下是抽象類的定義：
[public|protected] abstract class ClassName {
abstract void fun();
}
從定義上看，Java 中的抽象類就是用來繼承的，沒有被繼承的抽象類沒有任何實際的作用。而且，抽象類中的抽象方法只是起到一個限制的作用，並沒有提供實際的方法體，這也要求子類去實現自己的方法體。
將抽象類的特徵總結一下，大概有以下幾點：
在 Java 中，介面以 interface 定義，與 class 定義的類不同，如下是介面的定義：
[public|protected] interface InterfaceName {
void func();
}
介面實際上也可以包含變數和方法，但是，介面中的變數會被隱式地指定為 public static final 修飾的不可變數，介面中的方法會被隱式地指定為 public abstract 修飾的方法。
將介面的特性總結一下，大概有以下幾點：
從上述對抽象類和介面的簡單分析看，抽象類和介面的概念非常相似，從明面上看，其最大的區別就是，抽象類是用來繼承的，介面是用來實現的。
從更深層次的角度上看，抽象類是不能被範例化的類，只能被子類繼承，繼承關係表示的是一種 is-A 的關係，介面表示的是一種 has-A 關係。
在使用時，抽象類可以定義一些公共的屬性、方法，抽象方法用於宣告子類繼承的約束；介面的主要作用就是宣告實現的協定，但是相比抽象類的優勢就是一個類可以實現多個介面。
首先，只能被子類繼承的抽象類能解決程式碼複用的問題。
然後，抽象類表達的是一種抽象概念，適用於表示現實生活中的抽象概念。如狗是具體物件，動物則是抽象概念。
使用抽象方法，而非空的方法體，建立子類時就知道他必須要重寫該方法，而不能忽略。
使用抽象類，類的使用者建立物件的時候，就知道他必須要使用某個具體子類，而不是抽象類本身。
使用抽象類提高了安全性，降低了開發者犯錯的概率，是一種更優雅的編碼方式。
抽象類更多的作用是引導使用者正確使用，避免被誤用。
介面是對行為的一種抽象，相當於一組協定，更側重於解耦。
呼叫者只需要關注抽象的介面，不需要了解具體的實現，具體的實現程式碼對呼叫者透明。介面實現了約定和實現相分離，可以降低程式碼間的耦合，提高程式碼的擴充套件性。
如果抽象類只定義抽象方法，那抽象類和介面非常相似。但介面和抽象類在根本上是不同的，一個類可以實現多個介面，但只能繼承一個類。
抽象類和介面是配合而不是替代，它們經常一起使用，介面宣告能力，抽象類提供預設實現，實現全部或部分方法，一個介面經常有一個對應的抽象類。
比如，在 Java 類庫中有以下關係：
介面沒有成員變數，沒有方法實現，只有方法宣告，實現介面的類必須實現介面中的所有方法。
只要滿足上述幾個特點，從設計的角度上講，它就可以叫作介面。
在 Java 中，使用抽象類實現起來也比較簡單，即抽象類只定義抽象方法即可，缺陷就是子類無法繼承多個抽象類。
普通的類是可以包含具體實現的，這不符合介面的定義。但是，可以讓類中的方法丟擲 NoSuchMethodError 錯誤來模擬不包含實現的介面，並且強迫子類在繼承這個父類別時都去主動實現父類別的方法，否則就會在執行時丟擲異常。
為了避免普通的類被範例化，需要將這個類別建構函式宣告成 protected 存取許可權。
具體的程式碼實現如下：
public class MockInterface {
protected MockInterface() {}
public void funcA() {
throw new NoSuchMethodError();
}
}
同樣的，無論是使用抽象類還是普通類，實現的介面都無法滿足介面的所有特性，這裡也僅做一些瞭解。
在軟體開發中，最大的挑戰之一就是需求的不斷變化，因此，開發時一定要具有抽象意識、封裝意識、介面意識。
越抽象、越頂層、越脫離具體某一實現的設計，越能提高程式碼的靈活性、擴充套件性、可維護性。
這個時候，介面的存在就非常必要了，通過使用介面定義實現類的協定，將約定和實現分離，做到了解耦的效果。
在定義介面的時候，一些注意事項就是：命名一定要足夠通用，不能包含跟具體實現相關的字眼；另一方面，與特定實現相關的方法不要定義在介面中。
通常，越是不穩定的系統，越是要在程式碼的擴充套件性、維護性上下功夫。相反，某個系統特別穩定，在開發完成之後，基本不需要做維護，則沒有必要為其擴充套件性、維護性投入不必要的開發時間。