ดีไซน์แพตเทิร์นที่พบบ่อยในเฟรมเวิร์ก PHP มีอะไรบ้าง?

Question

Accepted Answer

เฟรมเวิร์ก PHP (Laravel, Symfony) สร้างขึ้นบน **ดีไซน์แพตเทิร์น** คลาสสิก ซึ่งเป็นทางออกที่นำกลับมาใช้ซ้ำได้สำหรับปัญหาการออกแบบที่พบบ่อย การรู้จักแพตเทิร์นเหล่านี้ช่วยให้คุณเข้าใจวิธีทำงานของเฟรมเวิร์กและเขียนโค้ดที่มีโครงสร้างดีขึ้นด้วยตัวเอง

## MVC (Model-View-Controller) — รากฐานทางสถาปัตยกรรม

```text
Model      → data + business logic (e.g. Eloquent models)
View       → presentation (templates: Blade, Twig)
Controller → handles requests, coordinates models & views
→ The structural pattern of nearly every PHP web framework.
```

## Dependency Injection / IoC Container

```php
// frameworks use a container to resolve & inject dependencies (decoupling, testability)
$service = $container->get(UserService::class);   // dependencies auto-wired
```

## Repository pattern — แยกการเข้าถึงข้อมูลออกเป็นนามธรรม

```php
interface UserRepository {
    public function find(int $id): ?User;
}
class EloquentUserRepository implements UserRepository { /* DB-specific impl */ }
// services depend on the INTERFACE → swap data sources, mock in tests
```

แพตเทิร์น **Repository** ทำให้การเข้าถึงข้อมูลเป็นนามธรรมอยู่หลัง interface แยก business logic ออกจากฐานข้อมูลและช่วยให้ทดสอบได้

## Factory — ห่อหุ้มการสร้างอ็อบเจกต์

```php
class PaymentFactory {
    public static function create(string $type): PaymentGateway {
        return match($type) {
            'stripe' => new StripeGateway(),
            'paypal' => new PayPalGateway(),
        };
    }
}
```

## แพตเทิร์นอื่น ๆ ที่พบบ่อยในเฟรมเวิร์ก PHP

```text
Singleton  → one shared instance (often via the DI container, e.g. config, DB connection)
Observer   → event/listener systems (Laravel events, model observers)
Strategy   → interchangeable algorithms (e.g. different cache/auth drivers)
Decorator  → wrap to add behavior (middleware-style request/response wrapping)
Facade     → a simple static interface to complex subsystems (Laravel Facades:
             Cache::get(), DB::table() — proxy to container-resolved services)
Adapter    → uniform interface over different implementations (e.g. filesystem drivers)
Active Record → models that wrap DB rows with query/save methods (Eloquent)
```

โดยเฉพาะ Laravel แสดงให้เห็นแพตเทิร์นเหล่านี้: **Facades** (static proxy ไปยังบริการต่าง ๆ), **Active Record** (Eloquent models), **Observer** (events/model observers), **Strategy** (driver ที่สลับเปลี่ยนได้สำหรับ cache, queue, auth)

## ทำไมจึงสำคัญ

ดีไซน์แพตเทิร์นเป็นความรู้สำคัญสำหรับนักพัฒนา PHP เพราะเฟรมเวิร์กหลัก ๆ (Laravel, Symfony) สร้างขึ้นบนแพตเทิร์นเหล่านี้ทั้งหมด การเข้าใจแพตเทิร์นจึงจำเป็นทั้งต่อการเข้าใจ *ว่าเฟรมเวิร์กเหล่านี้ทำงานอย่างไร* และต่อการเขียนโค้ดที่มีโครงสร้างดีด้วยตัวเอง

การรู้จัก **MVC** (รากฐานทางสถาปัตยกรรมของเฟรมเวิร์กเว็บ PHP แทบทุกตัว), **Dependency Injection / IoC container** (วิธีที่เฟรมเวิร์กเชื่อมโยง dependency เพื่อลดการผูกติดและทดสอบได้), แพตเทิร์น **Repository** (การทำให้การเข้าถึงข้อมูลเป็นนามธรรมเพื่อ persistence ที่ทดสอบได้และสลับเปลี่ยนได้) และแพตเทิร์นเฉพาะเฟรมเวิร์กอย่าง **Facades** ของ Laravel (static proxy ไปยังบริการ), **Active Record** (Eloquent models) และ **Observer** (events) ช่วยไขความลึกลับของ "เวทมนตร์" ของเฟรมเวิร์กเหล่านี้ และทำให้คุณใช้และต่อยอดมันได้อย่างมีประสิทธิภาพ

นอกเหนือจากการเข้าใจเฟรมเวิร์ก การรู้จักแพตเทิร์นที่พบบ่อยยังให้คำศัพท์ร่วมกันสำหรับการอภิปรายการออกแบบ ทางออกที่พิสูจน์แล้วสำหรับปัญหาที่เกิดซ้ำ และความสามารถในการออกแบบโค้ดที่บำรุงรักษาได้และยืดหยุ่น

เนื่องจากการพัฒนา PHP ระดับมืออาชีพแทบจะเกิดขึ้นภายในเฟรมเวิร์กที่เต็มไปด้วยแพตเทิร์น และเนื่องจากการออกแบบแอปพลิเคชันที่ดีอาศัยการใช้แพตเทิร์นอย่างเหมาะสม การเข้าใจดีไซน์แพตเทิร์นที่พบบ่อย ทั้งสิ่งที่มันแก้ไขและจุดที่มันปรากฏในระบบนิเวศ PHP จึงเป็นความรู้ระดับ senior ที่มีคุณค่า ซึ่งแยกแยะนักพัฒนาที่เข้าใจเครื่องมือของตนอย่างลึกซึ้งและสามารถสร้างแอปพลิเคชันที่มีสถาปัตยกรรมดี ออกจากผู้ที่ใช้เฟรมเวิร์กแบบผิวเผิน (ข้อควรระวังเช่นเคย: แพตเทิร์นเป็นเครื่องมือสำหรับปัญหาจริง ไม่ใช่เป้าหมาย การนำไปใช้ในจุดที่ไม่เหมาะสมจะเพิ่มความซับซ้อนที่ไม่จำเป็น)