HER YAZILIM GELİŞTİRİCİ BİLMELİ: SOLID PRENSIPLERI

SOLID Prensipleri her yazılım geliştiricinin bilmesi ve takip etmesi gereken bir konu. Meslekte güçlü olabilmek, çeşitli sorunlara en baştan çözümler sunabilmek için bu tür kavramları bilmenin ve uygulamanın faydalı olacağını düşünüyorum.

2000 Yıllarında Robert Cecil Martin(Halk arasında "Bob Amca" olarak bilinen Robert Cecil Martin, bir Amerikan yazılım mühendisi ve eğitmenidir.) kod karmaşıklığına, tekrar eden kodlara ve bir yazılımın kişiden bağımsız ilerlemesine yönelik bir takım çalışmalara imza atıyor. Bu çalışmalardan nesne yönelimli programlama için aşağıda bahsedeceğim 5 temel prensip ortaya çıkıyor.

·        S – Single Responsibility Principle (SRP): Tek sorumluluk anlamına gelen bu kuralın amacı projede bir değişiklik yapılmak istendiğinde buna bağlı olarak nelerin etkileneceği düşüncesinden kurtulmak ve özgürce isteğimiz geliştirmeyi yapabilmemize olanak sağlamaktır. Her bir method sadece kendisine verilen işi yapar aynı anda birden fazla modeli update etmez, örnek vermek gerekirse bir dizi işi yapan bir fonksiyon yazmaktansa tüm gereksinimleri parçalara ayırıp bağımsız fonksiyonlar ile yapmayı gerektiren bir kuraldır. Böylece zaman içerisinde geliştirme yaparken etkilenecek diğer aşamaları gözden kaçırmanız gibi bir risk oluşmaz.

Ø  Aşçı sınıfında YemekYap metodu olur fakat malzemeAl metodu olmaz ama Aşçı istese malzemeyi gidip alabilir. Lakin bu aşçının ana görevi değildir dolayısıyla gerek yoktur.

·        O – Open/Closed Principle (OCP): Açık kapalı prensibi projemizdeki nesnelerin geliştirmeye açık ama değişime kapalı olmaları anlamına gelmektedir. Oluşturduğunuz nesneler zaman içerisinde ek özellikler kazanabilir genişlemeye açık olurlar bu normal bir yazılım projesinde kaçınılmaz bir durumdur. Ama temel nesne değişime kapalı tutulmalıdır.

Ø  Bir şirkette çalışanların emeklilik günleri hesaplanacak. Her sınıf ayrı ayrı tanımlı işçi, memur vs ve her birinin bilgileri,işe giriş tarihleri sınıflarında tanımlı. Ne zaman emekli olduklarını hesaplamak için sgkHesap isimli sınıfımızda hesap metodu var. Patronumuz dedi ki buraya yöneticileri de ekle yöneticilerin de emeklilik günleri hesaplansın. Bunun için sadece sgkHesap kısmına if else koşullarıyla kontrol edilip hesaplatılmak istenen gün sayısının sahibi olan kişinin ne olduğu tespit edilerek yaptırılabilir.Hesap aynı hesap sadece değişen şey obje.

·        L – Liskov ‘s Substitution Principle (LSP): Yerine geçme prensibi kalıtım alarak türeyen nesnenin tüm özellikleri kullanmalı ve sonrasında kendi özelliklerini barındırmasını hedefleyen bir prensiptir. Eğer nesne kalıtım aldığı objenin tüm özelliklerini kullanmaz ise ortaya gereksiz kod yığınları oluşur ve sonrasında kalıtım alınan objenin diğerlerinden ayrılması için if-else bloklarına ihtiyaç olur. Bu durum son derece verimsiz bir yazılıma sebep olur.

Ø  Dörtgenler Üst sınıf ve kare alt sınıf olsun. dörtgen sınıfında tanımlı boyut değiştir metodu uzun kenarı 300 ve kısa kenarı 100 yapsın. Kare sınıfını bunun yerine geçirdiğiniz zaman(Kare de bir dörtgendir) karenin tüm kenarları eşit olduğu için bu metodu karşılayamaz ve bu yüzünden LSPye uymaz.

·        I – Interface Segregation Principle (ISP): Arayüz ayırım prensibi, bir arayüze gerektiğinden fazla yetenek eklenmemesi gerektiğini söyler. Nesnelerin ihtiyaç duymadıkları fonksiyonların Interface’lerinden münkün olduğunca ayrıştırılmasıdır.

Ø  İki boyutlu şekiller sınıfında hacim isimli bir metod tanımlamak. İki boyutlu şekillerin hacmi olmadığı için bu metod gereksizdir.

·        D – Dependency Inversion Principle (DIP): Bağımlılığın ters çevirilmesi ilkesine göre üst seviye sınıflar, modüller, methodlar vs. alt seviyeli sınıflara bağımlı olmamalıdır. Alt sınıflarda yapılan değişiklikler üst sınıfları etkilememelidir. Yüksek seviyeli sınıflar, düşük seviyeli sınıflara bağlı olmamalı, her ikisi de soyut kavramlara bağlı olmalıdır.

Ø  Yönetici ve işçi diye bir sınıfımız olsun. Yönetici sınıfımızın yeterince karmaşık olduğunu ve hem yöneticiye ait bilgilerin hem de işçiler üzerinde etki edebilecek metotları olduğunu düşünelim. Süper işçi diye yeni bir sınıf tanımladık. Ancak şu an yönetici sınıfındaki metotlar sadece işçilere hizmet veriyor ve bu durumda yönetici sınıfında çok büyük değişikliğe gitmemiz gerekecek çünkü oradaki metotların hepsi sadece işçiler için tasarlandı. Eğer dependency inversion prensibine uyulsaydı karmaşıklık minimum düzeye indirilebilirdi ve üst sınıf (yönetici) alt sınıf olan süper işçilere bağlı olmazdı.