Herkese merhaba, bu yazıda sizlerle her yazılımcının bilmesi gereken S.O.L.I.D prensipleriden bahsedeceğim. Öncelikle SOLID prensipleri neyi ifade ediyor ona bir göz atalım ardından neden ihtiyaç duyduğumuzdan ve son olarak da her bir prensibe teker teker değinelim. Hazırsanız başlayalım 🙂
SOLID prensipleri yazılımcının bir yazılım geliştirirken belli prensiplere uyarak yazılımı geliştirmesini ve geliştirilen yazılımın daha sürdürülebilir, yeniden kullanılabilir, kod tekrarı olmadan ve anlaşılabilir olmasını hedefler.
Neden yazılım geliştirirken sürüdürülebilir olması gibi etmenlere çok dikkat etmeliyiz ? Bunun için küçük bir örnek vermek istiyorum.
Bir inşaat mühendisi olduğunuzu düşünün. 5 katlı bir bina inşa etmeniz gerekiyor ve tüm hazırlıkları, planı ve projeyi çiziyor ve binayı inşa ediyorsunuz. Bu saatten sonra müşteri sizden ‘Ya 5 katlı yaptık ama biz bi 5 kat daha çıkalım’ demesi olasılıklar havuzunda çok düşük bir yere sahip. İstese bile bunun mümkün olması daha da düşük. Binayı inşa ederken her şeyi plana göre ayarladınız ve inşa ettiniz. Ekstradan çıkacağınız bir kat bütün mukavemeti değiştirebilecektir.
Lakin bir yazılım geliştirdiğiniz zaman bu durum böyle olmuyor. Müşteri yeni bir isteğini ilettiği zaman isteğin projeye kolayca entegre edilebilmesi gerekiyor. Bizler yukarıda saydığım sürdürülebilir ve yeniden kullanılabilir gibi etmenleri dikkate almadan proje geliştirirsek her yeni bir güncellemede projenin bir tık daha çökmesi ve nihayetinde başka bir yeniliği kabul etmeyecek bir düzeye gelmesi mümkün oluyor.
Bu tarz prensipler ve çeşitli yazılım kalıplarını öğrenerek geliştirdiğiniz proje daha kaliteli olacak ve bazı sorunları başınızdan def etmiş olacaksınız. Şimdi SOLID prensiplerine değinelim.
Single Responsibility Principle
Bu prensip bizlere her sınıfın bir sorumluluğunun olması gerektiğini söyler. Yapılacak değişiklikler ve güncellemeler bu sorumluluk doğrultusunda gerçekleşir. Örneğin network işlemleriniz için bir sınıf oluşturduysanız bu sınıf içerisinde network işlemlerinizi yaparsınız. Veritabanı kurulumu yada veritabanına sorgu işlemlerini bu sınıftan muaf tutar başka bir sınıfta bu işi çözersiniz.
Open Closed Principle
Bir sınıf geliştirildiğinde hali hazırda var olan özellik ve fonksiyonlarını korumalı ve değişikliğe izin vermemelidir. Yani sınıfımız değişmeyecek ama yeni özellikleri kabul edebilecek bir durumda olmalıdır. Bu prensiple aslında projenin başında tasarım ve mimarinin iyi bir şekilde oluşturulması gerektiğini de düşünebiliriz.
Liskov Substitution Principle
Kodlarımızda herhangi bir değişiklik yapmaya gerek duymadan alt sınıfları, kalıtım aldıkları super sınıflardan türetebilmemiz gerekir.
Interface Segregation Principle
Fonksiyonlarımızı tek bir interface üzerinde toplamak yerine ihtiyaçlarımızı birden fazla interface ile gidermeliyiz.
Dependency Inversion Principle
Bu prensip projemizdeki yapılar arasında bağımlılığın en aza indirgenmesini hedefler. Böylelikle gerçekleştireceğimiz en ufak bir değişiklik veya yenilik projeyi çok fazla etkilemeyecektir. Aksi durumda bir modelimiz içerisisinde yapacağınız en ufak bir tür dönüşümü bile projenizin çoğu yerinde kırmızı satırların oluşmasına sebep olabilir 🙂
