Java 接口與抽象類：核心差異、設計意圖與最佳實踐

基礎語法對比

核心設計哲學差異

接口：契約與多態

• 本質：定義「能做什麼」的規範契約
• 意圖：實現多態，解耦調用者與實現者
• 經典案例：Comparable、Runnable、Driver（JDBC）

抽象類：代碼復用與模板

• 本質：提取子類共同邏輯的「半成品」
• 意圖：減少重複代碼，定義算法骨架
• 經典案例：AbstractList、HttpServlet、模板方法模式基類

「是什麼」vs「能做什麼」判斷法

• IS-A 關係：Car extends Vehicle → 抽象類
• CAN-DO 關係：Car implements Drivable → 接口
• 反例：Bird implements Flyable（企鵝不飛）→ 應拆分為 Flyable/Swimmable 等細粒度接口

接口隔離與依賴倒置實踐

// 業務接口層
public interface UserService {
    User findById(Long id);
    void save(User user);
}

// 實現層依賴接口，而非具體類
@Service
public class UserServiceImpl implements UserService {
    @Autowired
    private UserRepository userRepo; // 依賴 Repository 接口
    
    public User findById(Long id) { return userRepo.findById(id).orElse(null); }
    public void save(User user) { userRepo.save(user); }
}

// Controller 僅依賴 Service 接口
@RestController
public class UserController {
    private final UserService userService; // 構造器注入
    
    public UserController(UserService userService) { this.userService = userService; }
}

Java 8+ 接口新特性

• default 方法：提供默認實現，避免破壞現有實現類
• static 方法：工具方法歸屬接口，如 Stream.of()
• 私有方法：default 方法間共享邏輯

選型決策樹

1. 需要多實現、跨體系整合 → 接口
2. 存在大量共享邏輯、狀態 → 抽象類
3. 兩者皆需 → 接口定義契約 + 抽象類提供骨架實現（如 Collection → AbstractCollection）

常見誤區澄清

❌ 「接口完全可以用抽象類替代」
✅ 抽象類無法解決多實現、跨繼承體系的多態需求

❌ 「所有方法都要定義在接口」
✅ 接口應保持精簡，遵循接口隔離原則

總結

接口定義「規範」，抽象類提供「骨架」。優先使用接口定義服務契約，提取共性代碼時引入抽象類。這是面向對象設計中「面向接口編程」與「模板方法模式」的語言級體現。