S.O.L.I.D. Yazılım Prensipleri

Her yazılımcının bilmesi gereken, yazılım geliştirmenin temel prensipleri olarak kabul edilmektedir.

Geliştirilen yazılımın esnek, yeniden kullanılabilir, sürdürülebilir ve anlaşılır olmasını sağlayan, kod tekrarını önleyen prensiplerdir.

Bu prensipleri üstat Robert C. Martin tarafından öne sürülmüş prensibler bütünüdür.

Bu prensiplerin amacı geliştirdiğimiz yazılımın gelecekteki gereksinimlere kolayca adapte olmasıdır. Bu gereksinimleri eklerken de kodda değişikliğe gerek kalmadan, yeni kodlar ile ekleyebilmeliyiz. Eğer mevcut kodlarda düzenleme yapmamız gerekiyorsa dahi bu prensipler ile yeniden kod yazmanın yol açtığı zaman kaybını minimuma indirmektedir.

Unutmayınız ki, eğer bir kodu güncellemeniz gerekiyorsa oluşturduğunuz mimarinizin bağımlılıkları yüksek demektir. Bu prensiplerin tümünü olabildiğince uyguladığınızda düşük bağımlılık (loosely coupled) içerin bir koda sahip olursunuz.

Bu prensipleri detaylı inceleyelim.

Single Responsibility Prensibi: Bir katman, bir class yada bir fonksiyonun sadece bir iş yapmasına dayanır.

Üye kaydı için bir sınıf oluşturduğunuzu düşünelim. Sınıf içinde fieldlarımızı tanımladıktan sonra, üye işlemleri için CRUD methodları eklememiz gerekiyor. Çünkü fieldlardan object üretmemiz gerekiyor. Yeni kullanıcı kaydı, şifre sıfırlama gibi işlemler iş katmanına aittir. Bununla ilgili Manager veya Service sınıfları yazmamız gerekiyor.

Open/Closed Prensibi: Bir sınıf veya fonksiyonun değişikliğine izin verilmemeli ama yeni feature eklenebilmesine izin vermesine dayanır. Robert Martin’inde dediği gibi tekrar kullanılabilir yapıda kod yazmanın temelidir.

E-ticaret sisteminize yeni bir ödeme türü eklemek istediğinizde, mevcut kodları değiştirmeden yeni kodlar ile eklemeniz gerektiğini söyler.

Liskov Substititution Prensibi: Alt sınıfları türedikleri üst sınıfların yerine kullanabilmesine dayanır.

Çözülmesi gereken problem aynı olsada, iki sınıf içindeki çözüm yöntemleri farklı olabilir. Bir interfacede inherit edilen iki sınıfında içindeki metodları override yaparak ilgili özelliklerine işlem yapmasını sağlamış oluruz.

Interface Segregation Prensibi: Interfacelerin daha çok özelleştirilmesine dayanır. Doğru parçalara ayrılmalıdır.

Birden fazla ödeme alma türü olan bir modül yapmanız isteniyor. Havale/EFT, kredi kartı veya ödeme kuruluşları ile ödeme alacaksınız. Her ne kadar aynı iş yapsalarda kendi içlerinde farklı özellikleri vardır. Hatta bankadan aldığınız sanal pos ile ödeme alma kuruluşlarından sanal poslar bile farklı özelliklere sahiptir. Burada yapmamız gereken bu ödeme alma yöntemlerinin özelliklerine göre interfaceler oluşturmaktadır.

Dependency Inversion Prensibi: Sınıflar arası bağımlılıklar olabildiğince az olmalıdır. Üst seviye sınıflar alt seviye sınıflara bağımlı olmamalıdır. Bağımlılıkların tersine çevirilmesidir.

Bu zaten IoC Container mantığıdır. Bunu üye kayıt işlemlerinde kullanabiliriz. Yaptığınız uygulamada hem bireysel, hemde kurumsal üye olabilir. Bu üyelik sınıflarını bir interface üzerinden ilgili üye kayıt işlemleri sınıfından çağırabiliriz. Böylelikle üst sınıf olan üye kayıt sınıfıyla bağımlılığını tersine çevirmiş oluruz.

Sonuç

Bu prensipler sayesinde sürdürebilirliği olan kodlar yazabileceksiniz. Ayrıca bu prensipleri uygularken farkında olmadan design patterns’leride kullanmış olursunuz.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.