4 Software Design Pattern yang Paling Sering Digunakan di Dunia Nyata (Real World)

4 Software Design Pattern yang Paling Sering Digunakan di Dunia Nyata (Real World)

Jika Circuit Breaker digunakan untuk mencegah *server crash*, maka Software Design Patterns adalah *blueprint* (cetak biru) untuk menulis kode yang rapi, mudah dibaca, dan gampang dikembangkan (*scalable*). Konsep ini dipopulerkan oleh buku legendaris "Gang of Four" (GoF).

Masalahnya, saat kita belajar *Design Pattern* di bangku kuliah, contoh yang diberikan biasanya sangat teoritis (seperti Class Hewan, Kucing, Anjing). Padahal di dunia nyata (*real world backend engineering*), *Design Pattern* digunakan untuk memecahkan masalah arsitektur bisnis yang rumit.

Berikut adalah 4 *Design Pattern* yang paling sering Anda temui (bahkan mungkin sudah Anda gunakan tanpa sadar) di *framework* modern seperti Laravel, Spring Boot, atau Django.

---

1. Singleton Pattern

Konsep: Memastikan sebuah *Class* hanya bisa diinisiasi (*instantiated*) satu kali saja selama aplikasi berjalan, dan memberikan akses global ke *instance* tersebut.

Penggunaan di Dunia Nyata: Koneksi Database.
Bayangkan Anda memiliki aplikasi yang melakukan 50 *query* SQL dalam satu *request*. Jika setiap *query* membuka koneksi baru ke MySQL, *database* Anda akan langsung mati karena batas koneksi (*Connection Limit Exceeded*). Dengan Singleton, koneksi hanya dibuka satu kali di awal, lalu 49 *query* sisanya menumpang pada jalur koneksi yang sama.

// Contoh logika Singleton di PHP
class Database {
    private static $instance = null;
    
    // Constructor di-private agar tidak bisa di-new dari luar
    private function __construct() {
        // Lakukan koneksi ke MySQL di sini
    }
    
    public static function getInstance() {
        if (self::$instance == null) {
            self::$instance = new Database(); // Hanya dipanggil 1x
        }
        return self::$instance;
    }
}

// Cara pakainya:
$db = Database::getInstance();

---

2. Strategy Pattern

Konsep: Membungkus algoritma ke dalam *Class* terpisah, sehingga kita bisa mengganti algoritma (*strategy*) yang digunakan saat aplikasi sedang berjalan (*runtime*), tanpa mengubah kode utamanya (Mendukung asas *Open-Closed Principle*).

Penggunaan di Dunia Nyata: Payment Gateway atau Metode Pengiriman.
Misalnya *E-commerce* Anda menerima pembayaran dari Stripe, PayPal, dan Midtrans. Daripada membuat blok if-else yang panjang dan berantakan, kita membuat *Interface* PaymentStrategy.

interface PaymentStrategy {
    public function pay($amount);
}

class MidtransPayment implements PaymentStrategy {
    public function pay($amount) { /* Hit API Midtrans */ }
}

class PayPalPayment implements PaymentStrategy {
    public function pay($amount) { /* Hit API PayPal */ }
}

class Checkout {
    public function prosesPembayaran(PaymentStrategy $metode, $jumlah) {
        return $metode->pay($jumlah);
    }
}

// Kapanpun bos Anda minta tambah metode pembayaran "OVO", 
// Anda hanya perlu membuat Class baru tanpa menyentuh Class Checkout!

---

3. Observer Pattern (Pub-Sub)

Konsep: Sebuah mekanisme di mana satu objek (Publisher) memberitahu banyak objek lain (Subscribers/Observers) jika terjadi suatu peristiwa (*event*), tanpa Publisher harus tahu siapa saja objek lain tersebut.

Penggunaan di Dunia Nyata: Event Listeners & Notifikasi.
Saat *user* berhasil mendaftar (Register) di web Anda, ada banyak aksi yang harus terjadi: 1. Kirim Email *Welcome*. 2. Buat Wallet internal. 3. Catat di Log. Daripada menulis semua logika itu di dalam *Controller* Register, kita melempar *Event* UserRegistered. *Class* lain yang bertugas mengirim email dan membuat wallet cukup "mendengarkan" (*Listen*) *event* tersebut. (Di Laravel, ini adalah fitur Events & Listeners).

// Pseudocode Listener
class SendWelcomeEmail implements Observer {
    public function handle($event) {
        // Kirim email ke $event->user->email
    }
}

---

4. Factory Pattern

Konsep: Sebuah "pabrik" (*Factory*) yang bertugas membuat objek. Daripada kita meng-new sebuah objek secara langsung, kita meminta *Factory* untuk membuatkannya berdasarkan kondisi tertentu.

Penggunaan di Dunia Nyata: Pengiriman Notifikasi Lintas Kanal.
Misalnya sistem Anda bisa mengirim OTP via SMS, WhatsApp, atau Email tergantung dari pilihan *user*.

class NotificationFactory {
    public static function create($tipe) {
        switch($tipe) {
            case 'SMS': return new TwilioSmsSender();
            case 'WA': return new WhatsAppSender();
            case 'EMAIL': return new SmtpEmailSender();
            default: throw new Exception("Tipe tidak valid");
        }
    }
}

// Cara pakai:
$sender = NotificationFactory::create($user->preferensi_otp);
$sender->send("Kode OTP Anda: 1234");

Kesimpulan

Menghafal nama-nama *Design Pattern* mungkin berguna untuk lulus *interview* kerja. Tetapi, memahami kapan dan mengapa Anda harus menggunakannya (seperti Strategy untuk Payment Gateway atau Observer untuk Notifikasi) adalah yang membedakan seorang *Programmer* biasa dengan seorang Software Architect yang andal.