SOLID Prensipleri: Örneklerle Sağlam Nesne Yönelimli Tasarım

Nesne yönelimli programlamayı öğrenmek görece kolaydır; sınıf, nesne, kalıtım gibi kavramları birkaç günde kavrarsınız. Zor olan, bu araçları kullanarak değişime dayanıklı sistemler tasarlamaktır. İşte SOLID tam da burada devreye girer. Robert C. Martin tarafından popülerleştirilen bu beş ilke, esnek, test edilebilir ve zamanla çürümeyen yazılımların iskeletini kurar. Bu yazıda her ilkeyi akademik tanımlara boğmadan, günlük geliştirme hayatından örneklerle ele alacağız.

S — Tek Sorumluluk İlkesi (Single Responsibility)

Bir sınıfın değişmesi için yalnızca tek bir nedeni olmalıdır. Yani her sınıf tek bir işten sorumlu olmalı. Bir sınıf hem veriyi doğruluyor, hem veritabanına yazıyor, hem de e-posta gönderiyorsa, üç ayrı sebeple değişmeye açık demektir ve her değişiklik diğerlerini riske atar.

// Kötü: tek sınıf üç iş yapıyor
class Kullanici {
    public function kaydet() { /* DB'ye yaz */ }
    public function dogrula() { /* alanları kontrol et */ }
    public function hosgeldinMailiGonder() { /* mail at */ }
}

// İyi: sorumluluklar ayrıldı
class Kullanici { /* sadece veri */ }
class KullaniciKaydedici { public function kaydet(Kullanici $k) {} }
class KullaniciDogrulayici { public function dogrula(Kullanici $k) {} }
class HosgeldinMaili { public function gonder(Kullanici $k) {} }

O — Açık-Kapalı İlkesi (Open/Closed)

Sınıflar genişlemeye açık, değişikliğe kapalı olmalıdır. Yani yeni bir davranış eklerken var olan, test edilmiş kodu değiştirmek zorunda kalmamalısınız. Bunu tipik olarak soyutlama ve çok biçimlilik (polymorphism) ile sağlarsınız.

interface OdemeYontemi {
    public function ode($tutar);
}

class KrediKarti implements OdemeYontemi {
    public function ode($tutar) { /* ... */ }
}

class Havale implements OdemeYontemi {
    public function ode($tutar) { /* ... */ }
}

// Yeni ödeme türü eklemek için mevcut kodu
// değiştirmeye gerek yok, yeni bir sınıf yeter.

Yeni bir ödeme yöntemi eklemek istediğinizde, dev bir if-else bloğunu düzenlemek yerine yalnızca yeni bir sınıf yazarsınız. Var olan kod hiç bozulmaz.

L — Liskov Yerine Geçme İlkesi (Liskov Substitution)

Bir alt sınıf, üst sınıfının yerine sorunsuzca geçebilmelidir. Yani bir kod üst sınıfla çalışıyorsa, herhangi bir alt sınıf verildiğinde de sürprizsiz çalışmalıdır. Klasik karşı örnek, "kare bir dikdörtgendir" tuzağıdır: bir Kare sınıfını Dikdörtgen'den türetip genişliği değiştirdiğinizde yüksekliğin de değişmesi, çağıran kodun beklentisini bozar.

Kalıtım bir "öyle görünüyor" ilişkisi değil, "her durumda yerine geçebilir" sözleşmesidir. Alt sınıf bu sözü tutamıyorsa, kalıtım yanlış araçtır.

I — Arayüz Ayrımı İlkesi (Interface Segregation)

Bir sınıf, kullanmadığı metotları uygulamaya zorlanmamalıdır. Kocaman, her şeyi kapsayan arayüzler yerine, küçük ve odaklı arayüzler tercih edilir.

// Kötü: şişkin arayüz
interface Calisan {
    public function kodYaz();
    public function tasarimYap();
    public function raporSun();
}

// İyi: küçük, odaklı arayüzler
interface Yazilimci { public function kodYaz(); }
interface Tasarimci { public function tasarimYap(); }

Böylece bir yazılımcı sınıfı, kullanmayacağı tasarimYap() metodunu boş boş uygulamak zorunda kalmaz.

D — Bağımlılık Tersine Çevirme (Dependency Inversion)

Üst düzey modüller alt düzey modüllere değil, ikisi de soyutlamalara bağlı olmalıdır. Somut sınıflara doğrudan bağlanmak yerine arayüzlere bağlanırsınız; böylece bileşenleri kolayca değiştirir ve test için sahte (mock) nesneler verebilirsiniz.

class SiparisServisi {
    private $bildirim;
    // Somut sınıfa değil arayüze bağımlı
    public function __construct(Bildirim $bildirim) {
        $this->bildirim = $bildirim;
    }
}

Bu yaklaşım, bağımlılık enjeksiyonunun (dependency injection) temelidir ve test edilebilir bir mimarinin anahtarıdır.

SOLID'i Dogma Değil, Rehber Olarak Kullanın

SOLID ilkeleri güçlüdür ama her satıra körü körüne uygulanmamalıdır. Basit bir betiğe beş arayüz katmanı eklemek, çözdüğünden fazla karmaşıklık yaratır. İlkelerin asıl amacı değişime dayanıklılıktır; bir kod parçası zaten sık değişmiyorsa, onu aşırı soyutlamak boşa efordur.

1. Önce sadeliği hedefleyin; karmaşıklık gerçek bir ihtiyaç doğduğunda gelsin.
2. SOLID'i "bu kod nasıl kolayca değişir?" sorusuna cevap ararken hatırlayın.
3. İlkeleri kural olarak değil, tasarım kararlarını değerlendiren bir mercek olarak kullanın.

Sonuç

SOLID prensipleri, nesne yönelimli tasarımda esneklik ve sürdürülebilirliğe giden bir pusuladır. Tek sorumluluk kodunuzu odaklı tutar, açık-kapalı genişlemeyi güvenli kılar, Liskov kalıtımı sağlam yapar, arayüz ayrımı bağımlılıkları hafifletir ve bağımlılık tersine çevirme test edilebilirliği açar. Bu ilkeleri deneyimle içselleştiren ekipler, büyüdükçe kırılmayan sistemler kurar. Berasoft'ta özel yazılım projelerimizi bu tasarım disipliniyle kurar, uzun ömürlü ve genişletilebilir çözümler üretiriz.