Merhaba arkadaşlar, bu yazımda size SOLID kısaltmasından bahsedeceğim. Tabi ki sadece kısaltmanın anlamından değil biraz detayından da bahsetmeye çalışacağım. SOLID aslında OOP(Object Oriented Programming yani Türkçesiyle nesneye dayalı programlama) yaparken uymamız gereken ilkeler denilebilir. Kullanımı zorunlu değildir ancak, kullanılmadığında çok başınızın ağrıyacağına garanti veriyorum kendi tecrübelerimden.
OOP denildiğinde akla gelen şey, okullarda bize gösterilen kalıtım, arayüzler vs. daha fazlası değil. Bu OOP kullanım tarzıyla geliştirmiş olduğum projelerde çalışmalarım devam ettikçe proje ömrünün ve yeniden kullanım imkanının çok az olduğunu farkettim. Yazılarımda Tasarım Desenleri bu sorunun çözüm kaynaklarından biri. Ancak etkili bir çözüm için SOLID ilkelerine uymak gerekiyor.
SOLID ilkeleri için basitçe söylemek gerekirse OOP ‘de bağımlılık yönetimi biçimidir. Bu ilkeler olmadan oluşturulan projeler esneyemez, kırılgan ve sabit özelliklerde oluyor. Yeni bir özellik ya da güncelleme yapmak istediğinizde projeyi baştan değiştirmeniz bile gerekebiliyor. Bunun nedeni kötü proje mimarisidir.
SOLID ilkelerinde anahtar kelime Loose Coupling yani gevşek bağımlılıktır. Sınıf ve arayüz ilişkilerinde bağımlılık ne kadar az olursa proje o kadar esnek olacaktır. Artık şu SOLID ‘i açıklayalım.
S – Single Responsibility Principle (SRP)
Bir sınıfın sadece bir sorumluluğu olmalıdır. Bir sınıf birden fazla işle ya da katmanla ilişkilendirilirse yönetimi ve geliştirimi zorlaşır.
O – Open/Closed Principle (OCP)
Bir sınıf gelişime açık, ancak değişime(mevcut kodların) kapalı olmalıdır. Bir sınıfa yeni bir özellik ekleme halinde sınıfın mevcut kodlarının değişmesi gerekiyorsa bu o sınıfın Loose Coupling kuralında uymadığı anlamına ve yeterli esneklik sağlamadığı anlamına gelir.
L – Liskov ‘s Substitution Principle (LSP)
Sınıfların kendi alt sınıflarıyla değiştirilebilir olması gerekmektedir. Basit bir örnek olarak çok biçimlilik konusu örnek verilebilir. Ancak bu durumun tam tersinin de işleyebiliyor olması gerekmektedir.
I – Interface Segregation Principle (ISP)
Arayüzlerin ayrımı anlamına gelen bu ilke, bir arayüzü implemente alan sınıfların gereksiz (kullanılmayan) metotları bulundurmaya zorlanmasının önlenmesidir. Mümkün olduğunda ortak özellikler arayüz halinde tasarlanmalı ve gerekirse farklı arayüzler birbirinden extend almalıdır.
D – Dependency Inversion Principle (DIP)
Yüksek seviyeli sınıflar, düşük seviyeli sınıflara bağımlı olmamalıdır her ikisi de soyut kavramlara bağlı olmalıdır. Çünkü somut sınıflarda değişikliklerin meydana gelme durumu daha fazladır.
Bu tanım sanırım oldukça genel ancak biraz daha açmak gerekirse, bir sınıf başka bir sınıf içerisinde bir örneği bulunduğu durumları göz önüne alalım. Bu sınıfta yapılmak istenecek ufak bir değişiklik O ilkesini çiğneyecektir. Bu yüzden farklı bir yaklaşım olarak bu sınıfları bir soyut sınıf veya arayüz yardımıyla birbirine bağlamak daha doğru olacaktır.
Bu ilkeler uyulması halinde geliştirdiğiniz her proje sizin için bir ilerleme olacaktır. Nasıl bir ilerleme derseniz, mesela her seferinde aynı sınıfları yeniden tanımlamak zorunda kalmazsınız. Daha önceki projelerinizdeki kodlarınızı Maven ve Tasarım Desenleri sayesinde yeni projeniz için adapte ederek bir adım daha atarsınız. Bu şekilde geliştirme yapmak size daha büyük projeleri daha kısa zamanlarda geliştirme imkânı verecektir.
EOC(End Of Code)
KuruKod 