SOLID

Single Responsibility
Open / Closed Principle
Liskov Substitution
Interface segregation principle
Dependency inversion

Single Responsibility

Single Responsibility prensibi, her bir sınıfın yalnızca bir işi yapması, bir sorumluluğa sahip olması gerektiğini belirtir. Örnek olarak elimizde ‘olayBildirim’ isimli bir sınıf olsun. Bu sınıfta hem olay bildirim bilgilerini tutup hem de olay bildirimi ile ilgili veritabanı işlemlerini (ekleme, güncelleme, silme) yaparsak single responsibility prensibini ihlal etmiş oluruz. Bu nedenle veritabı işlemleri için ‘olayBildirimRepository’ adlı başka bir sınıf kullanırız.

Open / Closed Principle

Open : Yazılım bileşenleri, mevcut kodu değiştirmeden yeni davranışlar ve özellikler eklemeye açık olmalıdır.

Closed: Yazılım bileşenleri, değişime kapalı olmalıdır. Mevcut kod yeni gereksinimlere uyum sağlamak için değiştirilmemelidir. Mevcut kodun değiştirilmesi değil genişletilmesi işlemi uygulanmalıdır. Bu şekilde yazılımın ömrü uzatılır. Bakımı kolaylaşır. Sürdürülebilir bir hale gelir.

Bir interface olsun. Bu arayüzü implement eden alt sınıflar olsun. Yazılım genişledikçe yeni sınıflar eklenir. Mevcut bir sınıf üzerinde değişiklikler yapılmaz.

Liskov Substitution

Alt sınıflar türetildikleri sınıfların davranış ve özelliklerini korumalıdırlar. Alt sınıflar üst sınıfların davranışlarını sağlamıyorsa LSP ihlal edilmiş olur.

public class Kus{
    void uc(){
        System.out.println("ucuyorum");
      }
}

Yukarıdaki sınıftan türetilen iki sınıf olsun. Birisi devekusu, diğeri de kartal olsun. Burada deve kuşu uçamayacağı için LSP ihlal edilmiş olur. Bunun yerine şöyle bir abstract sınıf tanımı daha uygun olur.

public abstract class Kus{
    abstract void hareket();
}

Bu sınıftan türetilen sınıflar, kendi hareket methodlarını oluştururlar ve ona göre de içini doldururlar. Örneğin şu şekilde:

class DeveKusu extends Kus {
    @Override
    public void hareket() {
        yuru();
    }

    public void yuru() {
        System.out.println("yuruyorum");
    }
}

Bu şekilde türetilen her bir alt sınıf kendi hareket şeklini implement eder.

Interface Segregation Principle

Çok fazla method içeren arayüzler yerine, yazılımın esnekliğini ve sürdürülebilirliğini artırmak için daha küçük arayüzler kullanılmalıdır. Yani bir sınıf kullanmayacağı bir methodu implement etmeye zorlanmamalıdır.

İki sınıfımız olsun. Birisi benzinliArac, diğeri elektrikliArac. Bu sınıflar ‘arac’ isimli bir arayüzü uygulasınlar. Bu arayüz içinde de benzinAl(), araciSarjEt() isimli method tanımlamaları olsun.

Bu durumda arac arayüzünü implement eden sınıflar hem benzinAl() hem de araciSarjEt() methodlarını da implement etmek durumunda kalacaklardır. Burada isp ihlal edilmiş olur. Bunun yerine ‘aracBenzinli’ ve ‘aracElektrikli’ isimli arayüzler tanımlanır ve sınıflar ilgili arayüzü implement eder.

Dependency Inversion Principle

Yüksek seviyeli sınıflar, düşük seviyeli sınıflar bağımlı olmamalıdır. Bunun yerine arayüzlere veya soyut sınıflara bağımlı olmalıdır.

Evimizde kullandığımız cihazlar üzerinden gidelim. ‘Firin’ ve ‘Calistir’ isimli iki sınıfımız olsun.

Fırını çalıştırmak isteyelim.

Burada DIP ihlal edilmiştir çünkü Calistir sınıfı Firin sınıfına bağımlı haldedir. Başka cihazlar çalıştırılmak istendiğinde ne yapacağız? Sınıfların bağımlılıklarını arayüzlere yönlendirmeliyiz.