Yazılımcılar, yazılım geliştirirken küçük ölçekli projelerde ve tek yazılımcı ile yürütülen süreçlerde genelde kendi kuralları ile yazılım geliştirirler. Bu kurallar da genelde nasıl başlarsan öyle gider mantığında ilerlemektedir. Fakat projenin büyüdüğü noktalarda veya ekibe yeni yazılımcılar katıldığında işler biraz daha karmaşık hal almaktadır. Bu süreci yönetebilmek için hemen hemen her meslekte olduğu gibi belli standartlar çerçevesinde yazılım geliştirmek hem hata yapmayı engeller hem de kod incelemelerinde kolaylıklar sağlar.
Bu kapsamda dünya üzerinde genel geçer kabul edilen yazılım geliştirme prensipleri mevcuttur. Bu prensiplerden birisi de SOLID prensipleridir.
SOLID bir isim değil bir kısaltmadır. Yukarıdaki görselde adımları ingilizce olarak belirtilmiştir. Şimdi konuyu biraz daha detaylandırarak 5 ana başlık halinde inceleyelim.
Single Responsibility Principle
Bu kuralın amacı uygulama geliştirme aşamalarında herhangi bir değişiklik yapılmak istendiğinde buna bağlı olarak nelerin etkileneceği düşüncesinden kurtulmak ve isteğimiz geliştirmeyi yapabilmemize olanak sağlamaktır. Her bir metot veya fonksiyon sadece kendisine verilen işi yapar aynı anda birden fazla modeli etkileyemez, ö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.
Open/Closed Principle
Bu kuralın amacı 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.
Liskov’s Substitution Principle
Bu kuralın amacı kalıtım (inheritance) alarak türeyen sınıfların kalıtım aldıkları nesnenin tüm özellikleri kullanmalı ve sonrasında kendi özelliklerini barındırmasını hedefleyen bir prensiptir. (Kalıtım hakkında bilginiz yoksa buraya tıklayınız.) eğer nesne kalıtım aldığı nesnenin tüm özelliklerini kullanmaz ise ortaya gereksiz kod yığınları oluşur ve sonrasında kalıtım alınan nesnenin diğerlerinden ayrılması için koşul bloklarına (if) ihtiyaç olur ve bu durum son derece verimsiz bir yazılıma sebep olur.
Interface Segregation Principle
Bu kural bir arayüze gerektiğinden fazla yetenek eklenmemesi gerektiğini söyler. Nesnelerin ihtiyaç duymadıkları fonksiyonların Interface’lerinden mümkün olduğunca ayrıştırılmasıdır.
Dependency Inversion Principle
Bu kurala göre ise üst seviye sınıflar, modüller, fonksiyonlar 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.
Tuncay UYAR 