Belajar Software Architecture and Design Patterns - Fondasi OOP untuk Pattern

#Pendahuluan

Setiap design pattern yang akan kalian pelajari dibangun dari bahan baku yang sama: empat pilar OOP. Menguasainya berarti membaca katalog pattern apa pun tanpa takut — termasuk yang tidak ada di series ini.

Episode ini membedah keempat pilar di tiga bahasa lab kita, lalu membahas keputusan paling penting dalam desain modern: komposisi atas inheritance.

#Pilar OOP

#Abstraction

Menyembunyikan detail, mengekspos kontrak:

interface PaymentGateway {
  charge(amount: number): Promise<{ id: string }>;
}

type PaymentGateway interface {
    Charge(amount int) (id string, err error)
}

interface PaymentGateway {
    public function charge(int $amount): array;
}

Perhatikan Go: interface didefinisikan di sisi konsumen dan dipenuhi secara implisit — tidak ada keyword implements. Ini keputusan desain bahasa yang membuat idiom Go condong ke interface kecil (akan terasa kuat saat membahas ISP di episode 4).

#Encapsulation & Inheritance

Encapsulation: state internal hanya bisa dimanipulasi lewat method yang mengatur invarian. Inheritance: reuse via hierarki class Child extends Parent — tersedia di TypeScript dan PHP; Go menggantinya dengan embedding struct.

#Polymorphism

Inti semua pattern behavioral: kode klien memanggil satu kontrak, implementasi bisa berganti tanpa perubahan. Ketiga contoh PaymentGateway di atas mendemonstrasikannya — klien menulis gateway.charge(...) tanpa peduli gateway itu Stripe, Midtrans, atau mock test.

#Komposisi > Inheritance

#Kenapa Pattern Modern Memilih Komposisi

Inheritance punya tiga masalah struktural:

1. Coupling statis — child terikat permanen ke detail parent; perubahan parent merambat ke seluruh pohon.
2. Fragile base class — refactoring parent yang tampak aman diam-diam memecah child.
3. Ekspresi buruk untuk kombinasi — "notifier yang retry + rate-limited + logging" butuh matriks subclass eksponensial kalau lewat inheritance.

Komposisi menyusun perilaku dengan cara menyuntikkan objek kecil yang saling independen — kombinasi bebas tanpa hierarki. Hampir seluruh GoF modern yang kita pakai (Strategy, Decorator, Adapter) adalah komposisi.

#Interface Segregation Praktis

Konsekuensi langsung: buat interface kecil dan fokus pada kebutuhan konsumen, bukan besar dan "lengkap". Interface 2–3 method mudah dipenuhi; interface 12 method adalah beban bagi setiap implementer. Kita dalami ini sebagai bagian SOLID di episode 4.

#Praktik

Target outline: refactor hierarki inheritance menjadi interface + composition di ketiga bahasa.

Skenario klasik yang melanggar: hierarki notifikasi via inheritance.

class Notifier { send(msg: string): void {} }
class EmailNotifier extends Notifier {}
class SmsNotifier extends Notifier {}
// kebutuhan baru: email+sms sekaligus? retry? -> ledakan subclass

interface Channel {
  send(to: string, msg: string): Promise<void>;
}
class EmailChannel implements Channel {
  async send(to: string, msg: string): Promise<void> { /* smtp */ }
}
class SmsChannel implements Channel {
  async send(to: string, msg: string): Promise<void> { /* api sms */ }
}
 
class RetryDecorator implements Channel { // kombinasi bebas
  constructor(private inner: Channel, private max: number) {}
  async send(to: string, msg: string): Promise<void> {
    for (let i = 0; i <= this.max; i++) {
      try { return await this.inner.send(to, msg); } catch { /* ulang */ }
    }
  }
}

type Channel interface {
    Send(to, msg string) error
}
 
type MultiChannel struct {
    channels []Channel // komposisi via slice
}
 
func (m *MultiChannel) Send(to, msg string) error {
    for _, ch := range m.channels {
        if err := ch.Send(to, msg); err != nil {
            return err
        }
    }
    return nil
}

interface Channel {
    public function send(string $to, string $msg): void;
}
 
final class Notifier {
    /** @param Channel[] $channels */
    public function __construct(private array $channels) {}
 
    public function notify(string $to, string $msg): void {
        foreach ($this->channels as $ch) {
            $ch->send($to, $msg);
        }
    }
}

Bandingkan hasilnya: kebutuhan kombinasi baru kini adalah menyusun argumen constructor, bukan membuat class baru. Inilah mesin di balik hampir semua pattern yang akan datang.

#Penutup

Rangkuman episode ini:

• Empat pilar: abstraction (kontrak), encapsulation (invarian), inheritance (reuse hierarki), polymorphism (ganti implementasi).
• Go memilih interface implisit di sisi konsumen — idiom interface kecil.
• Komposisi > inheritance karena coupling rendah, kombinasi bebas, tidak fragile; ISP praktis = interface kecil milik konsumen.

Episode 3 mulai seri SOLID: SRP (kenapa god-class adalah musuh utama) dan OCP (ekstensi tanpa modifikasi) — lengkap dengan refactor nyata di NestJS, Fiber, dan Laravel. Sampai jumpa!