solid

• s — (bkz: single-responsibility principle) (bkz: tek sorumluluk prensibi)
  o — (bkz: open-closed principle) (bkz: açık kapalı prensibi)
  l — (bkz: liskov substitution principle) (bkz: liskov değiştirme prensibi)
  ı — (bkz: ınterface segregation principle) (bkz: arayüz ayırma prensibi)
  d — (bkz: dependency ınversion principle) (bkz: ters bağımlılık prensibi)
  
  s:
  bir sınıfın ya da bir metodun tek bir görevi olmalıdır. ikinci, üçüncü görevlerin dahil edilmesi bu prensibe aykırıdır.
  öğretmen, mühendis, bakkal vb. class lar yerine gidip de ınsan diye bir class yazsak, sonra da bunların yapacakları tüm işleri bu classta tanımlasak çok büyük bir karmaşa ortaya çıkacaktır. bunun yerine öğretmen, mühendis, bakkal gibi (gerektiğinde bunları da dallandırarak) classlarla çalışarak bu prensibe ayak uydurabiliriz.
  
  o:
  uygulama gelişime açık, değişime kapalı olmalıdır.
  yazılım doğası gereği sürekli güncellenmektedir. sürekli yeni ihtiyaçlar, yeni durumlar ortaya çıkmaktadır. yani yazılım bir süreçtir. bu süreçte uygulama geliştirilebilmeli fakat değiştirilmemelidir.
  bu prensipte genel olarak gelişim anlaşılıyor fakat değişim anlaşılamıyor.
  değişimden kastımız nedir? uygulamaya yeni bir özellik, yeni bir durum eklendiğinde önceden yazdığımız kodu değiştirmeden, sadece ihtiyacımız olan yeni yere kod yazarak yapabiliyor olmalıyız.
  yukarıda bahsettiğim öğretmen, mühendis ve bakkal örneğine bir de doktor eklenmesi gerektiğinde, sadece doktor u ekleyip uygulamamın hazır olmasını bekleriz. örneğin maaş hesaplaması yapılan bir yere bir else if daha eklenmesi gereken bir durum oluşuyorsa bu open-closed principle'e aykırı olacaktır.
  
  l:
  bir classtan türetilmiş classlar birbirlerinin yerine kullanılabilir olmalıdır. ana classta belirtilen özellikler alt sınıflarda da eksiksiz yerine getirilebilmelidir.
  bilgisayar diye bir ana sınıfımız, asus ve dell diye de 2 alt sınıfımız olsun. bilgisayar ana sınıfımızı tanımlarken düşündük ve dedik ki bir bilgisayarın bir ana kartı, bir işlemcisi, bir ekran kartı, bir klavyesi, bir de kamerası olur dedik.
  her ne kadar bir bilgisayarın ana kartı, işlemcisi ekran kartı ve klavyesi oluyor olsa da kamerası olmayabilir. bu da liskov substitution principle'e aykırıdır.
  
  i:
  bir interface olması gerekenden daha fazla iş yapmaya zorlanmamalıdır. çünkü bu interface i implemente edecek sınıflar bunları yapmaya zorlanacaktır. eğer bu özellik desteklenmiyorsa sıkıntı yaşanacaktır.
  telefon diye bir interface tasarlayıp, içine fotografcek, internetebaglan, aramayap gibi metotlar eklemek yerine, fotografcekebilir, ınternetebaglanabilir, aramayapabilir gibi interfaceler yaparak classları ilgili interface lerden implemente etmek daha doğru olacaktır. çünkü her telefon fotoğraf çekemeyebilir ya da internete bağlanamayabilir. nokia3310 telefonunu telefon interface inden implemente edersek fotoğraf çek özelliğini, bu özelliği desteklememesine rağmen implemente etmek zorunda kalacağız ve ınterface segregation principle'ine aykırı davranmış olacağız.
  
  d:
  sınıfların birbirine bağımlılığı soyut kavramlar üzerinden yapılmalıdır. bir sınıf diğer bir sınıfa doğrudan bağlanmamalıdır. özellikle yüksek seviyeli bir class düşük seviyeli bir class a asla bağılmlı olmamalıdır.
  bunun için güzel bir örnek anahtar ve ampüldür.
  bir ampül classımızın olduğunu düşünelim ve içinde de yak() ve sondur() metotları olsun.
  bir de anahtar classımız olsun. anahtar bir ampüle ve bir de anahtarla() metoduna sahip olsun. anahtarla metodu da eğer açıksa söndürsün, sönükse açsın.
  bu şekilde yapılan tasarımda, anahtar gibi hem ampül yakıp söndürebilecek hem de başka cihazları da açıp kapayabilecek derecede yüksek seviyeli bir class iken bizim tasarımımızda sadece ampül açıp kapayabiliyor. daha sonra başka bir cihaz açıp kapamak istersek anahtar sınıfını kullanamayacağız.
  
  bunun yerine anahtarlanabilir diye bir interface oluşturup ve içine de ac() ve kapa() diye bir metot eklersek ampülü soyutlamış oluruz. daha sonra anahtar içinde ampül kullanmak yerine anahtarlanabilir interface ini kullanırsak anahtar anahtarlanabilir olan bütün classları açıp kapayabilecektir.