Solid Prensipleri - Genel
Uygulama geliştiricileri olarak, uygulamayı son derece verimli, hızlı ve esnek bir şekilde tasarlamak çok önemlidir. Yazılan kodun uzun vadede ne kadar işlevsel ve korunaklı olduğu kritiktir ve diğerlerine rakip kılacak önemli noktalardan biridir. Peki bu nasıl sağlanır? Cevap çok basit, SOLID prensipleri :)
SOLID prensiplerinin beş ilkesini anlamak ve yazılan kodu bu ilkeler doğrultusunda geliştirmek profesyonel anlamda geliştiricileri ileriye taşır. SOLID’in 5 ilkesi doğrudan ilişkili olmasa bile aynı hedefe hizmet eder. SOLID’i biraz daha detaylı inceleyelim.
SOLID’in 5 ilkesi:
- S → Single Responsibility (Tek Sorumluluk Prensibi)
- O → Open-Closed (Açık/Kapalı Prensibi)
- L → Liskov Substitution (Liskov Yerine Geçme Prensibi)
- I → Interface Segregation (Arayüz Ayırma Prensibi)
- D → Dependency Inversion (Bağımlılıkları Tersine Çevirme Prensibi)
1- Single Responsibility (Tek Sorumluluk Prensibi)
Her modülün, sınıfın veya işlevin yazılım tarafından sağlanan işlevselliğin tek bir bölümünden sorumlu olması gerektiğini ve bu sorumluluğun tamamen sınıf tarafından kapsanması gerektiğini belirten bir ilkedir. Her bir method yalnızca kendisine verilen işi yapar aynı anda birden fazla modeli güncellemez. Bir çok işi yapan fonksiyon yazmak yerine gereklilikleri modüllere ayırıp her biri için bağımsız fonksiyonlar kullanmayı gerektiren bir kaidedir. Bu durumda ileride oluşabilecek değişikliklerde risk azalır.
2- Open-Closed (Açık/Kapalı Prensibi)
Bu ilkeye göre modüller, sınıflar, entitiyler gelişime açık ancak değişikliğe kapalı olmalıdır. Değişiklikler bu ilkeye göre yalnızca yeni kodlar dahil edilerek yapılmalıdır. Burada kritik olan kısım temel nesne değişime kapalı olmalıdır.
3- Liskov Substitution Principle — Liskov Yerine Geçme Prensibi
Bir programdaki nesneler, o programın doğruluğunu değiştirmeden alt tiplerinin örnekleriyle değiştirilebilir olmalıdır. Yani türetilmiş sınıf nesnelerinin türetilen sınıf yerine geçmesine Liskov yerine geçme prensibi denir. Ana sınıf üzerinde olan tüm özellikler alt sınıflar tarafından da kullanılabilir durumda olmalıdır.
4- Interface Segregation (Arayüz Ayırma Prensibi)
İstemciye özel birçok arabirim, tek bir genel amaçlı arabirimden daha iyidir mantığına dayanan bir ilkedir. Pratikte aslında protokolleri ayırmamız anlamına gelir. Herhangi bir arayüze gerekenden fazla işlev eklenmemesi gerektiğini söyler. Nesneler zorunlu ihtiyaç duymadığı fonksiyonların arayüzlerinden ayrışmalıdır.
5- Dependency Inversion (Bağımlılıkları Tersine Çevirme Prensibi)
Bağımlılıkları tersine çevirme prensibinde genel amaç alt seviyeli sınıflara doğrudan bağımlılığı olmayan üst seviyeli sınıflar oluşturmaktır. Bu ilkeyi kısaca araya direkt bağımlılığı olmayan protokoller yazarak sağlayabiliriz. Üst seviyeli sınıfların da alt seviyeli sınıflarında soyut kavramlara bağlı olması, üst seviyeli sınıfların alt seviyeli sınıflara herhangi bir bağı olmamasının sağlanması kritiktir.
Bu yazımda kısaca, tüm yazılım dillerinde ve projelerinde kullanılması profesyonel önem taşıyan SOLID prensiplerinin genel amaçlarından bahsettim. Umarım faydalı olmuştur. Bir daha ki yazımda görüşmek üzere :)
