SOLID kavramı nedir?

SOLID Prensipleri: Kodunu Daha Yönetilebilir Hale Getirme Sanatı

SOLID, yazılım geliştirme dünyasında her ciddi programcının bilmesi gereken temel bir prensipler bütünü. Robert C. Martin (Uncle Bob) tarafından popülerleştirilen bu beş prensip, yazdığın kodun zamanla daha sürdürülebilir, anlaşılır ve esnek olmasını sağlar. Kısacası, kodunun "ömrünü uzatır".

1. Single Responsibility Principle (SRP) - Tek Sorumluluk Prensibi

Bu prensip diyor ki, bir sınıfta veya modülde yalnızca tek bir değişiklik nedeni olmalı. Yani, bir sınıfın yapması gereken tek bir işi olmalı. Örneğin, bir `Kullanici` sınıfın varsa, hem kullanıcı bilgilerini tutmalı hem de veritabanına kaydetme işini yapmamalı. Veritabanı işlemleri için ayrı bir sınıf (`KullaniciRepository` gibi) oluşturmak, SRP'ye uymaktır.

Deneyimlerime göre, bu prensibe uymayan kodlarda değişiklik yapmak kabusa dönüşür. Bir fonksiyonda küçük bir değişiklik yapmak istersin ama aynı fonksiyonda ilgisiz başka işler de yapıldığı için farkında olmadan başka yerleri bozarsın. Kodun modülerleşmesi, test yazmayı da inanılmaz kolaylaştırır. Her sınıfın tek bir sorumluluğu olduğunda, o sınıfı izole edip kolayca test edebilirsin.

1. Open/Closed Principle (OCP) - Açıklık/Kapalılık Prensibi

Bu prensip der ki, bir yazılım varlığı (sınıf, modül, fonksiyon vb.) genişletmeye açık olmalı, ancak değişikliğe kapalı olmalı. Yani, mevcut kodu değiştirmeden yeni özellikler ekleyebilmelisin. Bunun en yaygın yolu soyutlamalar (interface, abstract class) kullanmaktır.

Diyelim ki bir `RaporOlusturucu` sınıfın var ve başlangıçta sadece `PDFRaporu` üretiyor. Daha sonra `ExcelRaporu` da eklemek istediğinde, mevcut `RaporOlusturucu` sınıfını değiştirmeden, sadece yeni bir rapor sınıfı (`ExcelRaporu`) oluşturup, bir soyutlama (`IRapor`) üzerinden bu raporu ekleyebilirsin. Mevcut çalışan kodunu bozmadan yeni özellikler ekleyebilmek, sistemin kararlılığını artırır.

1. Liskov Substitution Principle (LSP) - Liskov Yerine Geçme Prensibi

Barbara Liskov'un adını taşıyan bu prensip, bir sınıfta (alt sınıf), onun ana sınıfının (üst sınıf) yerine geçtiğinde programın doğruluğunu bozmamalıdır. Kısacası, alt sınıflar üst sınıfların özelliklerini beklendiği gibi taşımalıdır. Bir üst sınıfın bir nesnesini, alt sınıfın bir nesnesiyle değiştirdiğinde, programın davranışı değişmemeli.

Örneğin, bir `Kus` ana sınıfın ve `Suri` ile `Penguen` alt sınıfların varsa, `Suri` `ucmak` fiilini yerine getirebilirken, `Penguen` uçamaz. Eğer `Kus` sınıfında zorunlu bir `uc` metodu varsa ve `Penguen` bu metodu uygulayamıyor veya boş bırakıyorsa, LSP ihlal edilmiş olur. Çünkü bir `Kus` nesnesini beklediğin yere bir `Penguen` nesnesi koyduğunda beklenmedik bir hata alırsın.

1. Interface Segregation Principle (ISP) - Arayüz Ayrıştırma Prensibi

Bu prensip, istemcilerin (yani bir arayüzü kullanan sınıfların) kullanmadıkları metotlara bağımlı olmaya zorlanmamaları gerektiğini söyler. Büyük, tek bir arayüz yerine, küçük ve özel arayüzler oluşturmak daha iyidir.

Diyelim ki bir `IPrinter` arayüzün var ve içinde `print()`, `scan()` ve `fax()` metotları bulunuyor. Eğer bir makinen sadece `print()` yapabiliyorsa, o makineyi `IPrinter` arayüzüne bağladığında, `scan()` ve `fax()` metotlarını da uygulamak zorunda kalır ki bu mantıksızdır. Bunun yerine, `IPrinter`, `IScanner`, `IFax` gibi ayrı ayrı arayüzler oluşturursan, her sınıf sadece ihtiyaç duyduğu arayüzlere bağımlı olur.

1. Dependency Inversion Principle (DIP) - Bağımlılık Tersine Çevirme Prensibi

Bu prensip iki kısımdan oluşur:

1. Üst seviye modüller alt seviye modüllere bağımlı olmamalıdır. Her ikisi de soyutlamalara (abstactions) bağımlı olmalıdır.
2. Soyutlamalar detaylara (concrete implementations) bağımlı olmamalıdır. Detaylar soyutlamalara bağımlı olmalıdır.

Kısacası, kodunun yüksek seviyeli modüllerinin, düşük seviyeli modüllerine değil, soyutlamalarına (interface veya abstract class) bağımlı olması gerekir. Ve bu soyutlamalar da, concrete (somut) implementasyonlarına değil, soyutlamaların kendisine bağımlı olmalıdır.

Bir `ServisKatmani` sınıfın var ve bu sınıf doğrudan `VeriErisimKatmani` somut sınıfına bağlıysa, bu DIP ihlalidir. Bunun yerine, `IVeriErisim` gibi bir arayüz tanımlayıp, `ServisKatmani`'nın bu arayüze bağımlı olmasını sağlarsın. `VeriErisimKatmani` ise bu arayüzü uygular. Bu, "Injection" (Enjeksiyon) dediğimiz yöntemiyle (örneğin Constructor Injection ile) sağlanır. Böylece `ServisKatmani`, hangi somut veri erişim sınıfının kullanılacağını bilmek zorunda kalmaz, bu kontrol başka bir yere (genellikle bir IoC container'a) bırakılır.