🚀 Laravel 與設計模式：從框架原理到企業級架構實戰
在 Laravel 的世界中，設計模式（Design Patterns）並非只是面試時背誦的術語，而是支撐整個框架靈活性與可維護性的靈魂。理解這些模式與 Laravel 功能的對應，是從 Junior 邁向 Senior 的關鍵分水嶺。
一、 Laravel 設計模式全景圖
Laravel 本身就是設計模式的最佳實踐場景。下表完整整理了框架內建功能與設計模式的映射關係：
| 設計模式 | Laravel 核心實現 | 實務應用場景 |
| 工廠模式 (Factory) | Eloquent Model Factory | 產生測試偽資料、狀態變形（state）、模型關聯構建 |
| 建造者模式 (Builder) | Query Builder, Mailables | 動態構建複雜 SQL、鏈式呼叫配置郵件內容 |
| 單例模式 (Singleton) | Service Container, Cache | 全域唯一實例，避免資料庫或快取服務重複連線開銷 |
| 策略模式 (Strategy) | Filesystem Drivers, Notification | 切換支付渠道（LinePay/ApplePay）、切換儲存介質（S3/Local） |
| 裝飾模式 (Decorator) | Middleware Pipeline | 在 Request/Response 前後添加行為（驗證、日誌、CORS） |
| 外觀模式 (Facade) | Cache::, DB:: | 提供靜態介面隱藏 Service Container 複雜的解析過程 |
| 儲存庫模式 (Repository) | Custom Interface Binding | 解耦 Controller 與 Eloquent，利於單元測試與資料源替換 |
| 觀察者模式 (Observer) | Model Events & Observers | 使用者註冊後寄信、訂單成立後扣減庫存、發送 Push |
二、 核心模式深入解析與程式碼實戰
1. Middleware：裝飾模式 (Decorator) 的極致應用
Laravel 的 Middleware 實作了「洋蔥模型」，每個 Middleware 就像一個裝飾器包裹住核心邏輯，能在請求進入 Controller 前（前置處理）或回傳 Response 後（後置處理）添加功能。
// 自訂實務範例：記錄請求處理時間
class ExecutionTimeMiddleware
{
public function handle($request, Closure $next)
{
// 1. 前置處理：記錄啟動時間
$start = microtime(true);
// 2. 傳遞給下一個裝飾器 (或核心邏輯)
$response = $next($request);
// 3. 後置處理：計算並記錄執行時間
$duration = microtime(true) - $start;
Log::info("Request processed in {$duration} seconds");
return $response;
}
}
2. 多支付系統：策略模式 (Strategy) 的完美解決方案
為了符合開閉原則 (Open-Closed Principle)，當系統需要支援多種支付方式時，策略模式是最佳選擇。
// 1. 定義策略介面
interface PaymentGateway
{
public function charge(array $data);
}
// 2. 實作具體策略
class CreditCardGateway implements PaymentGateway {
public function charge(array $data) { /* 刷卡邏輯 */ }
}
class LinePayGateway implements PaymentGateway {
public function charge(array $data) { /* LinePay 邏輯 */ }
}
// 3. 在 Controller 中根據需求動態切換策略
public function checkout(Request $request)
{
// 利用 match 語法選擇策略
$gateway = match ($request->payment_method) {
'credit_card' => app(CreditCardGateway::class),
'line_pay' => app(LinePayGateway::class),
default => throw new \Exception('不支援的支付方式'),
};
// 執行支付任務
return $gateway->charge($request->all());
}
3. Facade 原理：隱藏複雜度的「靜態外觀」
Laravel Facade 經常被誤解為純靜態方法，實際上它是透過 __callStatic() 魔術方法，動態從 Service Container 中解析出實例並呼叫。
// 自訂 Facade 範例
use Illuminate\Support\Facades\Facade;
class MyApi extends Facade
{
/**
* 指定要從 Container 中解析的 Key
*/
protected static function getFacadeAccessor()
{
return 'my-api-service';
}
}
// 使用時：MyApi::getUsers();
// 實際上是執行：app('my-api-service')->getUsers();
三、 面試必問情境與架構權衡
1. 為什麼 Cache 服務應該使用單例 (Singleton)？
面試回答點：初始化快取連線（如 Redis）需要網路開銷。單例模式確保在同一個 Request 生命週期內只會建立一次連線。此外，快取配置在整個請求中應保持一致，單例能防止狀態不一。
2. Repository Pattern 的必要性？
資深觀點：雖然 Eloquent 本身已經是 ActiveRecord 模式，但在大型專案中，Repository 能將查詢邏輯與業務邏輯分離。
好處：當你想從 MySQL 換到 MongoDB，或者需要 Mock 資料庫進行 Unit Testing 時，只需更換 Interface 的實現，而不需要更動 Controller。
四、 給開發者的成長建議
閱讀底層源碼：
觀察
Illuminate\Pipeline\Pipeline如何實作 Middleware 的裝飾鏈。觀察
Illuminate\Database\Eloquent\Builder如何利用建造者模式生成 SQL。
避免過度設計 (Over-engineering)：
設計模式是為了解決「變動」帶來的維護成本。如果專案極小，直接在 Controller 寫 Eloquent 查詢（ActiveRecord）可能比強行拆分 Repository 更具效率。
測試驅動觀點：
寫不出測試通常是因為程式碼耦合度太高。嘗試使用策略模式與介面注入，你會發現 Mocking 變得異常簡單。
五、 結語
Laravel 不只是一個快速開發工具，更是一部活生生的設計模式教科書。當你理解了 Facade 背後的 Container 解析，理解了 Middleware 背後的 Pipeline 裝飾，你就能在面試中不僅僅是「回答問題」，而是能「討論設計哲學」。
下次寫程式碼時，問自己一個資深工程師的問題：
「如果明天老闆要換掉這個支付套件或資料庫，我的程式碼需要改幾個地方？」
沒有留言:
張貼留言