Solid Prensipleri Nedir?

Bu makalede yazılım sektöründe belkide OOP ile beraber en sık duyulan kavramlardan biri de Solip prensipleridir. Peki tam olarak nedir bu solid prensipleri? Makale içerisinde tek tek tüm solip prensipleri ile alakalı açıklamaları bulabilirsiniz.

Solid Prensipleri Nedir?

Solid Prensipleri Nedir?

Solid prensipleri Robert Cecil Martin aracılığıyla 2000’li yıllarda hayatımıza girdi. OOP geliştirme yapmak için uyulması gereken bazı kurallardan oluşmaktadır.

  1. (S)ingle Responsibility Principle(Tek Sorumluluk Prensibi): Her method ve class’ın tek bir sorumluluğu olur örnek olarak database işlemleri yapan bir class içerisinde log’lama işlemlerini yürüten işlemler konulmamalı yada loglama class’ımız var ise bu class içerisinde loglama haricinde başka bir şeylerin dahil edilmemesi gerekiyor ve metod’lardada aynı şekilde switch/case ile yönlendirmemek gerekiyor her metodun tek bir sorumluluğu olmalıdır.
  2. (O)pen/Closed Principle(Açık/Kapalı Prensibi): Değişime kapalı ama geliştirmeye açık şekilde kodlamanın kurgulanması gerekiyor mesela bugün log’lamaları xml’de yapıyorsunuz ama bir karar ile loglamanın artık xml’de değilde database’de yapılması istendi, varolan kodlarınızda değişiklik değil güncelleme yapılması gerekiyor misal olarak xml log’laması yapan Single Reponsibility kuralına uymuş olan bir class’ınız var ve bu class ILogger arayüzünden türetilmiş Database loglaması yapacak class’ımızda bu arayüzden türetilip metod içerikleri ona göre yazılır böylelik bu değişiklik değil geliştirme olmuş olur. Kısacası Uygulama gelişime açık, değişime kapalı olmalıdır. Yani yeni eklenen bir modül için kodda gereksiz if blokları gibi değişiklikler olmamalıdır. Bunun yerine kalıtım yoluyla sorun çözülmelidir.
  3. (L)iskov ‘s Substitution Principle(Liskov’un yerine geçme prensibi): Liskov’un yerine geçme prensibi alt sınıflardan oluşturulan nesnelerin üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorunda olduklarını söyler. Yani;türetilen sınıflar, türeyen sınıfların tüm özelliklerini kullanmak zorundadır. Eğer kullanmaz ise ortaya işlevsiz, dummy kodlar çıkacaktır. Bu durumda üst sınıfta if else blokları kullanarak tip kontrolü yapmamız gerekebilir ve böylelikle Açık Kapalı prensibine de ters düşmüş oluruz. Interface Segregation Prinsiple kısmında interface’le üzerinden bu konu anlatılırken burada abstract class’lar üzerindeki kullanımdan bahsediliyor.
  4. (I)nterface Segregation Principle(Arayüz ayrımı prensibi): Bir arayüze gereğinden fazla kullanılmayacak özellik eklenmemelidir. Kullanılabilecek özellikler, metodlar eklenerek kullanılmalıdır.
  5. (D)ependency Inversion Principle(Bağımlılığın ters çevrilmesi prensibi): Bu prensibe göre de bir sınıf diğer bir sınıfa doğrudan bağımlı olmamalıdır. Aralarındaki bağ soyut bir kavram üzerinden sağlanmalıdır. Bu soyut kavram interface de olabilir abstract class da olabilir.

Solid’e ek olarak Kiss, Yangi, Dry, Reuse Release Equivalence, Common Closure prensipleri de bulunmaktadır.

Kiss(Keep it Simple Stupid – Basit Aptal Tutmak): Bir problemin birçok durumda birden fazla çözümü vardır ve biz yazılımcılar kendi bilgi/birikimlerimizi en iyi yansıtan, en karmaşık kod yapısını kullanmaya eğilimli olabiliyoruz. Kiss prensibine göre çözümlerimiz mümkün olduğunca sade/anlaşılır olmalı. En basit ve en optimum çözüm yöntemini seçerek uygulama geliştirmeliyiz.

Yangi(You Aren’t Gonna Need It! – Buna ihtiyacım yok!): Yangi prensibine göre, “o an” ihtiyacımız olmayan kodları sisteme dahil etmemeliyiz, ileride eklenebilecek özellikler hakkında öngürüde bulunup ek geliştirmeler yapmamalıyız.

Dry(Don’t Repeat Yourself – Kendinizi Tekrar Etmeyin): Proje içerisinde aynı kodu tekrar tekrar yazıyorsanız dry prensibine uymuyorsunuz demektir. Tekrarlı kod yapısında değişiklik olması, kullandığınız her yerde tek tek değiştirmenizi gerektirebilir ve ayrıca sistemi gereksiz yere karmaşık hale getirecektir. Böyle bir durumda, tekrarlı kodları merkezileştirecek bir çözüm üretmemiz gerekmektedir.

Reuse(Release Equivalence Principle): Sistemde kullanılan paketler/namespace’ler arasındaki bağımlılıkları yönetmek “tekrar kullanılabilir” yapılar kurmakla mümkün olur.

Common Closure(Ortak Kapama Prensibi): Single Responsibility’nin namespace’ler için uyarlanmış halidir. Aynı sebepten değişebilecek sınıflar aynı namespace altında bulunmalıdır. Böylelikle sistemde oluşabilecek değişikliklerin tüm sistemi etkilemesinin önüne geçilmesi amaçlanır.

📚 İlgilenebileceğiniz diğer makaleler


✍ Lütfen olumlu-olumsuz tüm görüşlerinizi bana yorum yada mail yolu ile iletmeyi ihmal etmeyin.

🔗 Sosyal medya kanallarından makaleyi paylaşarak destek olursanız çok sevinirim.

👋 Bir sonraki makalede görüşmek dileğiyle.

2 Cevaplar

  1. sercan dedi ki:

    Makaleniz gerçekten çok açıklayıcı olmuş ama bol örnek ve demo projeler ile desteklerseniz mükemmel olur.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir