SOLID nedir? Yazılım mülakatlarının vazgeçilmez sorusu. Birçoğunuzun da bildiği gibi SOLID nesne yönelimli tasarımı daha anlaşılır, esnek ve sürdürülebilir hale getirmek için ortaya çıkan 5 tasarım prensibinin isimlerinin baş harflerinden oluşturulan bir kısaltmadır.
Bu prensipler ilk olarak 2000 yılında “Design Principles and Design Patterns” isimli makale ile Amerikalı yazılım mühendisi ve eğitmen olan Robert C. Martin tarafından yazılım dünyasına tanıtılan tasarım prensiplerinin bir alt kümesidir.
SOLID kısaltması ise daha sonra 2004 yılında Michael Feathers tarafından ortaya atılmıştır.
Peki nedir bu prensipler?
S – Single Responsibility Principle (Tek Sorumluluk Prensibi)
Single Responsibility Prensibine göre temelde her sınıfın veya modülün tek bir sorumluluğu olması gerekir. Yani aslında bir sınıfın veya modülün değiştirilmesi/güncellenmesi için sadece bir sebebin, yani üslendiği sorumluluğun değişmesi gerektiğini anlatır. Okuması daha kolay ve daha sürdürülebilir bir kod yapısı amaçlar.
Örnekli anlatım için Single Responsibility Prensibi yazısını ziyaret edebilirsiniz.
O – Open-Closed Principle (Açık-Kapalı Prensibi)
Open-Closed Prensibi bir sınıfın veya modülün gelişime açık ancak değişime kapalı olması gerektiğini söyler. Kısaca yeni bir işlev eklenmek istendiğinde var olan sınıfta güncelleme yapmak yerine o sınıftan türetilen yeni bir sınıf içerisinde tanımlama yapılması olarak düşünülebilir. Daha esnek ve bakımı kolay bir kod yapısı amaçlar.
Örnekli anlatım için Open-Closed Prensibi yazısını ziyaret edebilirsiniz.
L – Liskov Substitution Principle (Liskov Yerine Geçme Prensibi)
Liskov Substitution Prensibine göre alt seviye sınıfların üst seviye sınıfların yerine geçebilir olması gerekir. Alt sınıftan ürettiğimiz bir nesneyi üst sınıftan ürettiğimiz bir nesneyle değiştirebiliyor ve programın çalışması herhangi bir şekilde bozulmuyorsa Liskov Substitution Prensibine uyuyor diyebiliriz.
Örnekli anlatım için Liskov Substitution Prensibi yazısını ziyaret edebilirsiniz.
I – Interface Segregation Principle (Arayüz Ayırma Prensibi)
Interface Segregation Prensibi bir Interface‘in o Interface‘i kullanan sınıflara sadece ihtiyaçları olan metotları sunması gerektiğini belirtir. Yani bu prensibe göre bir sınıfın ihtiyacı olmayan bir özelliği tanımlamasına gerek olmamalıdır, bunun için de farklı işlevlere odaklanan özelleşmiş birden fazla Interface oluşturmak daha uygundur.
Örnekli anlatım için Interface Segregation Prensibi yazısını ziyaret edebilirsiniz.
D – Dependency Inversion Principle (Bağımlılıkları Tersine Çevirme Prensibi)
Dependency Inversion Prensibine göre üst seviye sınıflar veya modüller alt seviye sınıflara veya modüllere bağımlı olmamalıdır, ikisi de soyutlamalara bağımlı olmalıdır. Bu bağımlılıklar genellikle Interface’ler ve Abstract sınıflar aracılığıyla kurulur. Bu prensip daha esnek, bakımı ve testi daha kolay bir kod yapısı kurulmasına yardımcı olur.
Örnekli anlatım için Dependency Inversion Prensibi yazısını ziyaret edebilirsiniz.
Sonuç
Sonuç olarak, SOLID prensipleri, yazılım geliştirme sürecimizi daha düzenli, sürdürülebilir ve hata toleranslı hale getirmek için güçlü bir araçtır. Bu prensipleri benimsemek, kod tabanlarımızı daha etkili bir şekilde yönetmemizi ve uzun vadede daha başarılı projelere imza atmamızı sağlayacaktır.
Sonraki yazılar:
Single Responsibility Prensibi
Open-Closed Prensibi
Liskov Substitution Prensibi
Interface Segregation Prensibi
Dependency Inversion Prensibi