PHP 抽象類與介面深度對比：語法差異、設計意圖與選型指南

選型決策樹（遵循《Effective Java》Item 20）

1. 是否需要共享代碼/狀態？ → 是 → 抽象類
2. 是否需多重繼承行為？ → 是 → 介面 (PHP 單繼承限制)
3. 是否定義「是一種」關係？ → 是 → 抽象類 (如 Dog is Animal)
4. 是否定義「能做什麼」能力？ → 是 → 介面 (如 Flyable, Serializable)
5. 需向第三方開放擴展？ → 介面更安全（不暴露內部結構）
6. 需提供預設實現供可選覆寫？ → PHP 8.0+ 介面 default 方法，或抽象類

進階：介面 + 抽象類組合模式

interface RepositoryInterface {
  public function find($id);
  public function save(Entity $e);
}

abstract class BaseRepository implements RepositoryInterface {
  protected $pdo;
  public function __construct(PDO $pdo) { $this->pdo = $pdo; }
  // 通用邏輯：事務、事件分發、日誌
  public function save(Entity $e) {
    $this->pdo->beginTransaction();
    try {
      $this->doSave($e);
      $this->pdo->commit();
    } catch (\Throwable $ex) {
      $this->pdo->rollBack();
      throw $ex;
    }
  }
  abstract protected function doSave(Entity $e); // 子類實現具體 SQL
}

class UserRepository extends BaseRepository {
  protected function doSave(Entity $e) { /* user 表具體邏輯 */ }
}

「介面定義契約，抽象類提供骨架，具體類填充細節」—— 這是 PHP 面向對象設計的黃金分層。

常見誤區

• 濫用抽象類做工具類：純靜態方法集合用 final class + private __construct()
• 介面定義常量被子類覆蓋：介面常量不可覆蓋，編譯期報錯
• 以為 implements 後必須實現所有方法：若類聲明 abstract 可延遲實現

理解語法邊界與設計意圖，才能在「繼承複用」與「組合契約」間做出正確架構決策，避免「為了用介面而用介面」的過度設計。