Yazılım dünyasında bir kodun sadece “çalışması” yetmez; aynı zamanda esnek, geliştirilebilir ve kolay tamir edilebilir olması gerekir. İşte Robert C. Martin tarafından geliştirilen SOLID ilkeleri, bize “kaliteli kodun” yol haritasını sunar.

S – Tek Sorumluluk (Single Responsibility): Herkes Kendi İşine!

Bir aşçının aynı zamanda garsonluk yapıp, kasaya baktığını ve bulaşıkları yıkadığını düşünün. İşler karışırdı, değil mi? Yazılımda da bir sınıf veya fonksiyon sadece tek bir işten sorumlu olmalıdır. Rapor hazırlayan kod, aynı zamanda o raporu mail atmaya çalışmamalıdır.

O – Açık/Kapalı İlkesi (Open/Closed): Yeniliğe Açık, Değişime Kapalı

Bir Lego setine yeni parçalar ekleyebilirsiniz ama mevcut parçanın şeklini değiştiremezsiniz. Yazılımda da sistem yeni özellikler eklemeye “açık”, ancak mevcut çalışan kodu bozacak köklü değişikliklere “kapalı” olmalıdır.

L – Liskov’un Yerine Geçme (Liskov Substitution): Taklitler Aslını Yaşatmalı

Eğer bir “Kuş” sınıfınız varsa ve altına “Penguen” ekliyorsanız, penguenin uçamıyor olması sistemde hata çıkarmamalıdır. Alt sınıflar, ana sınıflarının yerine geçtiğinde sistemi bozmamalı, onların temel görevlerini eksiksiz (veya mantıklı bir şekilde) yerine getirmelidir.

I – Arayüz Ayrımı (Interface Segregation): İhtiyacın Olmayanı Dayatma

Bir akıllı saat aldığınızı ama saatle birlikte size kocaman bir ütü masası kullanma zorunluluğu getirildiğini hayal edin. Ne alaka, değil mi? Yazılımda da bir sınıfa kullanmayacağı özellikleri zorla yüklememeli, yetenekleri daha küçük ve spesifik parçalara bölmeliyiz.

D – Bağımlılığı Tersine Çevirme (Dependency Inversion): Priz ve Fiş Uyumu

Evinizdeki lambayı doğrudan duvardaki kabloya lehimlemezsiniz; bir priz kullanırsınız. Böylece lamba bozulursa sadece lambayı değiştirirsiniz, duvarı kırmanıza gerek kalmaz. Yazılımda da büyük parçalar küçük parçalara göbekten bağlı olmamalı; araya bir “standart” (priz gibi bir arayüz) koyarak sistemi esnek tutmalıyız.