Yazılımda SOLID Prensipleri: Nedir ve Neden Önemlidir?

Herkese Selamlar! 👋

Bu yazımda size, teknik mülakatlarda sıklıkla karşılaşılan ve yazılım dünyasında temiz kodun temellerinden biri olarak kabul edilen SOLID prensiplerinden bahsedeceğim. Bu prensipleri anlamak, hem yazılım geliştirme süreçlerinizde işinizi kolaylaştırır hem de teknik mülakatlarda sağlam bir temel oluşturmanızı sağlar.

Amacım, bu teorik gibi görünen konuları mümkün olduğunca sade, basit ve anlaşılır bir şekilde aktarmak. Teknik detaylara boğulmadan örneklerle ilerleyeceğiz. Hadi başlayalım! 🚀

SOLID Nedir ve Neden Önemlidir?

SOLID, yazılım geliştirmede kullanılan beş temel prensibin baş harflerinden oluşan bir kısaltmadır. Bu prensipler, kodunuzun daha anlaşılır, esnek ve sürdürülebilir olmasını sağlar. Özellikle büyük projelerde ve ekip çalışmalarında bu prensipleri benimsemek, hem bug çözmeyi kolaylaştırır hem de yeni özellikler eklemeyi zahmetsiz hale getirir.

SOLID prensiplerinin amacı, yazılım geliştirme sürecinde kodun daha okunabilir, bakımı kolay ve yeniden kullanılabilir olmasını sağlamaktır.

İşte SOLID prensiplerinin kısa bir özeti:

• S: Single Responsibility Principle (Tek Sorumluluk Prensibi)
• O: Open/Closed Principle (Açık/Kapalı Prensibi)
• L: Liskov Substitution Principle (Liskov Yerine Geçme Prensibi)
• I: Interface Segregation Principle (Arayüz Ayrımı Prensibi)
• D: Dependency Inversion Principle (Bağımlılığı Tersine Çevirme Prensibi)

Şimdi, bunları tek tek ele alalım ve her birini gerçek hayat senaryolarıyla açıklayalım.

1. Single Responsibility Principle

“Bir sınıf ya da metot, yalnızca bir sorumluluğa sahip olmalıdır.”

Bunu şu şekilde düşünebilirsiniz: Bir sınıf ya da metot her işi yapmaya çalışırsa, karmaşa kaçınılmaz olur. Sadece bir işi iyi yapması gerektiği için, işleri ayırmak gerekir.

Örnek;

Bir sınıf düşünün: Hem loglama yapıyor hem de veri tabanına bağlanıyor. Single responsibility prensibine göre bu iki sorumluluk ayrı olmalıdır.

class Logger {
    public void Log(string message) {
        Console.WriteLine(message); // Loglama işlemi
    }
}

class Database {
    public void Connect() {
        Console.WriteLine("Database'e bağlanıldı."); // Veritabanı bağlantısı
    }
}

Yukarıdaki örnekle görüldüğü üzere her bir sınıf, kendi işine odaklanıyor. Birisi loglama yaparken, diğeri veri tabanı bağlantısıyla ilgileniyor.

2. Open/Closed Principle

“Kodunuz genişletmeye açık, ancak değiştirmeye kapalı olmalıdır.”

Yeni bir özellik eklemeniz gerektiğinde, mevcut kodu değiştirmek yerine, yeni kod eklemelisiniz. Böylece mevcut sistemin stabilitesini bozmadan ilerlersiniz.

Örnek;

Bir ödeme sistemi düşünün. Yeni bir ödeme yöntemi eklemek istediğinizde eski kodu değiştirmek yerine yeni bir sınıf ekleyebilirsiniz.

interface IPayment {
    void Pay();
}

class CreditCardPayment : IPayment {
    public void Pay() {
        Console.WriteLine("Kredi kartıyla ödeme yapıldı.");
    }
}

class PayPalPayment : IPayment {
    public void Pay() {
        Console.WriteLine("PayPal ile ödeme yapıldı.");
    }
}

Bu şekilde, yeni bir ödeme yöntemi eklemek istediğinizde sadece yeni bir sınıf oluşturursunuz.

3. Liskov Substitution Principle

“Bir sınıf, türediği üst sınıfın yerine kullanılabilir olmalıdır.”

Eğer bir alt sınıf, üst sınıfın beklenen davranışını değiştirmeye çalışıyorsa, bu prensip ihlal edilmiş demektir.

Örnek: Bir kuş sınıfı düşünün. Penguenler uçamaz, ama tüm kuşların uçması bekleniyorsa sorun yaşanır.

class Bird {
    public virtual void Fly() {
        Console.WriteLine("Kuş uçuyor.");
    }
}

class Sparrow : Bird { }

class Penguin : Bird {
    public override void Fly() {
        throw new Exception("Penguenler uçamaz!");
    }
}

Bu tasarım hatalıdır çünkü Penguin sınıfı üst sınıfın yerine geçemez. Çözüm, uçabilen ve uçamayan kuşları ayırmaktır.

4. Interface Segregation Principle

“Her sınıf, sadece ihtiyaç duyduğu özellikleri içeren interfaceyi kullanır.”

Bir arayüzün gereksiz bağımlılıklar içermemesi gerekir.

Örnek: Bir yazıcı düşünelim. Yazıcı tarama özelliğine sahip değilse, tarama metodunu implement etmek zorunda kalmamalıdır.

interface IPrinter {
    void Print();
}

interface IScanner {
    void Scan();
}

class BasicPrinter : IPrinter {
    public void Print() {
        Console.WriteLine("Yazdırma işlemi yapıldı.");
    }
}

Yukarıdaki örnekteki gibi, her sınıf sadece ihtiyaç duyduğu özellikleri içeren arayüzü kullanır.

5. Dependency Inversion Principle

“Yüksek seviyeli sınıflar, düşük seviyeli sınıflara değil, soyutlamalara bağımlı olmalıdır.”

Bu prensip, bağımlılıkları daha esnek hale getirir. Biz alt seviyeli bir sınıfta herhangi bir değişiklik yaptığımız zaman, bu değişiklikten üst sınıf etkilenmemelidir.

Örnek: Bir bildirim sistemi düşünelim.

interface IMessageSender {
    void SendMessage(string message);
}

class EmailSender : IMessageSender {
    public void SendMessage(string message) {
        Console.WriteLine($"Email gönderildi: {message}");
    }
}

class Notification {
    private IMessageSender _messageSender;

    public Notification(IMessageSender messageSender) {
        _messageSender = messageSender;
    }

    public void Notify(string message) {
        _messageSender.SendMessage(message);
    }
}

Bu sayede Notification sınıfı, e-mail göndermek yerine başka bir mesajlaşma yöntemine kolayca uyarlanabilir.

SONUÇ

SOLID prensiplerini öğrenmek, hem yazılım geliştirme süreçlerinizi iyileştirir hem de teknik mülakatlarda sağlam bir temel oluşturmanıza yardımcı olur. Bu prensiplerin her biri, yazılımınızı daha esnek, sürdürülebilir ve anlaşılır hale getirmek için önemli bir yol göstericidir. Her birini uygulamak, daha kaliteli ve hatasız bir kod üretmenizi sağlar.

Buraya kadar okuduğunuz için teşekkürler, happy coding! 🚀