SOLID, yazılım geliştirme sürecinde kodun sürdürülebilirliğini, esnekliğini ve bakımını kolaylaştırmayı amaçlayan beş temel prensibi içeren bir kısaltmadır. Bu prensipler, Robert C. Martin tarafından tanıtılmış olup nesne yönelimli programlamada (OOP) en iyi uygulamaları belirlemek için kullanılmaktadır. Her bir prensibin baş harfleri ile oluşturulmuş prensipler şunlardır:
1- Single Responsibility Principle (SRP)
Single Responsibility Principle (Tek Sorumluluk İlkesi) Bir sınıfın yalnızca bir sorumluluğu olmalıdır. Yani, bir sınıf yalnızca tek bir amaç için değiştirilebilir olmalıdır. Bu prensip, kodun daha modüler olmasını sağlar ve bakımını kolaylaştırır.
2- Open/Closed Principle (OCP)
Open/Closed Principle (Açık/Kapalı İlkesi) Bir yazılım bileşeni genişlemeye açık, ancak değişime kapalı olmalıdır. Yani, mevcut kod değiştirilmeden yeni özellikler eklenebilir olmalıdır.
Örnek: Eğer bir ödeme yöntemi eklemek istiyorsak mevcut "Payment" sınıfını değiştirmek yerine, yeni bir "CreditCardPayment" veya "PayPalPayment" sınıfı oluşturarak mevcut sistemi bozmadan genişletebiliriz.
3- Liskov Substitution Principle (LSP)
Liskov Substitution Principle (Liskov Yerine Koyma İlkesi) Bir alt sınıf, üst sınıfının yerine sorunsuzca kullanılabilmelidir. Eğer bir alt sınıf, üst sınıfın beklenen davranışlarını bozuyorsa, bu prensip ihlal edilmiş olur.
Örnek: Eğer bir "Kare" sınıfı "Dikdörtgen" sınıfından türetilmişse ve dikdörtgenin genişliğini değiştirdiğimizde beklenmedik bir sonuç alıyorsak, bu prensip ihlal edilmiş olur.
4- Interface Segregation Principle (ISP)
Interface Segregation Principle (Arayüz Ayrımı İlkesi) Bir sınıf, kullanmadığı metotları içeren geniş ara yüzlere bağlı olmamalıdır. Bunun yerine, daha küçük ve odaklanmış ara yüzler kullanılmalıdır.
Örnek: Yanlış kullanım: Tek bir "Çalışan" ara yüzünün hem yazılım mühendisleri hem de yöneticiler için aynı metotları içermesi.
Doğru kullanım: "Yazılım Mühendisi" ve "Yönetici" için ayrı ara yüzler oluşturmak, böylece her biri sadece kendi ihtiyacı olan metotları içerir.
5- Dependency Inversion Principle (DIP)
Dependency Inversion Principle (Bağımlılıkların Ters Çevrilmesi İlkesi) Üst seviyedeki modüller, alt seviyedeki modüllere doğrudan bağımlı olmamalıdır. Bunun yerine, her ikisi de soyutlamalara bağımlı olmalıdır.
Örnek: Bir "EmailService" sınıfının doğrudan "SMTPClient" sınıfına bağımlı olması yerine, genel bir "IEmailSender" arayüzü üzerinden çalışması, bağımlılıkları azaltır ve alternatif e-posta servislerine geçişi kolaylaştırır.
SOLID prensipleri, yazılım geliştirme süreçlerinde daha temiz, modüler ve sürdürülebilir kod yazılmasına yardımcı olur. Bu prensiplere uyulduğunda, sistemler daha az hata içeren, daha esnek ve değişikliklere daha kolay adapte olabilen yapılar haline gelir. Yazılım mühendisleri, SOLID prensiplerini benimseyerek daha kaliteli ve ölçeklenebilir projeler geliştirebilirler.
