Eğer yazılım ve kodlama dünyasının bir parçasıysanız, bu kavramla mutlaka bir yerlerde karşılaşmışsınızdır.

SOLID Prensipleri her yazılımcının bilmesi gerektiği düşünülen, etkili, esnek ve doğru kodlama standartlarının sağlanması için takip edilmesinin doğru olduğu prensipler bütününe verilen bir adlandırmadır. SOLID, temel olarak 5 prensibin oluşturduğu kombinasyonun baş harflerinden oluşan bir kavramdır.

Robert C. Martin tarafından öne sürülen prensipler Robert C. Martin yani Bob Amca tarafından Desingn Principles and Desing Patterns kitabında tanıtılmıştır. Kısaltmasından meydana gelen isimlendirme fikrini ise Michael Feathers tanımlamıştır.

Genel olarak SOLID Prensiplerinin amacı;

  • Kodumuzun güncelleme ve düzenlemelere, yeni sürümlere kolayca adapte olmasını sağlamak,
  • Kolay adapte olmasını sağlayarak kod değişikliğini en kısa ve en kolay seviyeye indirmek,
  • Temiz kod yazmayı sağlamak ve gereksiz, karmaşık kodlamadan kaçınmak,
  • Kodu esnek bir şekilde kullanmak,
  • Kullandığımız dilin ve OOP mantığının bize kazandırdığı tüm sınırları ve güçleri bilmek ve kullanmak,
  • Yazılan kodu okuyan her kişi tarafından yeterince anlaşılır kılmak gibi amaçlara sahip olduğunu söyleyebiliriz.

Doğru ve iyi kod standartlarını belirleyen bu prensipleri daha detaylı bir şekilde açıklamaya devam edelim.

 

S- Single Resposibility Principle (Tek Bir Sorumluluğa Sahip Olma)

Bu prensipte savunulan görüş her sınıfın ancak tek bir sorumluluğu taşımaları gerektiğidir. Her sınıf en basit anlamda gerçekleştirebileceği tek bir sorumluluğu üstlenirse hem görev paylaşımı doğru bir şekilde yapılmış olur hem de programın ilerleyen zamanlarda değiştirilmesi, bakıma alınması çok daha kolay olur.

Sınıflara da tek bir sorumluluk yüklenmesinin yanında metotlar için de aynı görüş geçerli kabul edilmiştir. Yani bir metot hem ekrana çıktı verirken hem hesaplama, hem de raporlama gibi birden çok görevi tek metot ismi içerisinde yerine getirmemelidir. Birbirine bağlanmış sorumluluklar ilerleyen zamanlarda bakım ve geliştirme aşamalarında beklenenden çok daha fazla hata alınmasına sebep olabilir.

Basitlik kolaydır. Sınıfların çok kalabalık ve fazla sorumluluğa sahip olması editörü de pek çok açıdan zorlar. Eğer bir sınıf veya metodu değiştirmek için birden fazla sebebimiz varsa o yapı SRP kavramına uymuyor demektir.

 

O- Open-Closed Principle (Açık-Kapalı Prensibi)

Burada savunulan en temel düşünce sınıflarımızın geliştirmelere açık ancak değişikliklere kapalı olmasıdır. OOP mantığının da temelini oluşturan bu düşünce bize Get/Set, Private ve Abstract gibi kullanımlarla bu prensibi yerine getirmemizi sağlar. Sınıfımız kendi özelliklerini net değişikliklerden korurken aynı zamanda geliştirmelere ve yeni eklemelere açık olmalıdır.

Böylelikle sınıflarımızı hem koruyup hem de geliştirebilir, kontrolü programlama mantığının ötesinde elimizde tutmaya devam edebiliriz. Bu prensibi gerçekleştirmek için dillerin bize sağladığı özellikleri ve sınırları çok iyi bilmek ve tüm kabiliyetiyle kullanmak gereklidir.

Örneğin, rapor oluşturan bir sınıfımız varken, yeni bir rapor türünü oluşturmak istiyorsak burada zaten var olan rapor oluşturma sınıfımızdan miras almamız gerekir. Yeni rapor türü için ayrı bir sınıf açmak bu prensibe aykırı olacaktır.

 

L- Liskov Substitution Principle (İkame Edilebilirlik)

3.prensibimizde ise sınıflar arası ilişkilerin düzenlenmesinden bahsedilen bir durum söz konusudur. Yukarıdaki resimde de görüldüğü gibi eğer bir ördek varsa, ördek gibi görünüyorsa ve hatta ördek gibi ses çıkarıyorsa, ancak bir pile ihtiyacı varsa yani gerçek değil de oyuncak bir ördekse yanlış bir kalıtım söz konusudur.

Eğer bir alt sınıf kendisinden kalıttığımız üst sınıfın tüm özelliklerini sağlamazsa burada kalıtımla alakalı bir hata vardır diyebiliriz. Alt sınıfın nesneleri, üst sınıfla yer değiştirdiğinde aynı davranışları sergileyebilmelidir. Bu durumu ise “Is a?” testleri ile kontrol edebiliriz.

Bu prensip kalıtım mantığının doğru bir şekilde anlaşılması ve kullanılması konusunda bizi yönlendirmek için vardır. Kalıtım alınan sınıfın içerisindeki özellikler kendisinden kalıtılan sınıfta da doğru eve eksiksiz bir şekilde kullanılmalıdır. Aksi durumlar prensibe aykırıdır.

 

I- Interface Segregation Principle (Arayüz Ayırma İlkesi)

Prensip interface yapısını doğru bir şekilde kullanmayı sağlar. Yani gereksiz interface kullanımı ve gereksiz olanları kullanmaya zorlamaya çalışılmamalıdır. Eğer bir interface oluşturulduysa belirli bir amacı olmalı ve o amacı yerine getirebilmelidir.

Single Responsibility ilkesinin interfaceler için düzenlenmiş tipidir diyebiliriz.

Tüm metotları kapsayan tek bir interface yapısına sorumlulukların hepsini yüklemek yerine, görevleri daha ince bir şekilde tanımlanmış halde belirli, küçük gruplara hizmet eden interfaceler olmalıdır.

 

D- Dependency Inversion Principle (Bağımlılığı Tersine Çevirme)

Bağımlılık özelliği OOP mantığında işleyen diller için kullanımı ve kodlamayı oldukça kolaylaştıran özelliklerden biridir. Nesneleri, sınıfları ve metotları gerektiği şekilde bağlamak ve görevleri istenilen yerde tekrar etmeden tekrar kullanabilmek doğru bir şekilde olduğunda büyük bir kolaylık sağlar.

Ancak bağımlılıklarda geri kalan her özellik gibi doğru bir şekilde kullanılmalı ve çağırılmalıdır. Robert C. Martin bu prensibi 2 maddeyle şöyle açıklamaktadır;

  • Üst seviye (High-Level) sınıflar alt seviye (Low-Level) sınıflara bağlı olmamalıdır, ilişki abstraction veya interface kullanarak sağlanmalıdır,
  • Abstraction detaylara bağlı olmamalıdır. Tam tersi detaylar soyutlamaya bağlı olmalıdır.

Alt seviyede olan herhangi bir işlemin değişikliğe uğrayabilecek olması, kendisine bağlı olan tüm düzeni bozabilir. Bu nedenle yapılabilecek değişiklikler göz önüne alınarak bağımlılıkların düzeni bozmayacak şekilde düzenlenmesi gerekir.

Bağımlılıkları birbirine sıkı sıkıya bağlanmış olan metotlarda tekrar kullanılabilirlik imkansız hale gelir ve bu doğru kod yazmada isteyebileceğimiz şeylerden biri değildir.