Geçtiğimiz haftalarda SOLID yazı serisini sonlandırdık ve sırasıyla
konularından bahsettik.
İlk defa SOLID'i araştırırken bir çok blog yazlım forum sitesi vs. dolaştım ve yapılan yorumları okuma fırsatım olmuştu. Bu yorumlardan en çok yaygın olanı kabaca şöyle bir şey "ya tamamda ne gerek var bunca şeye ?.. SOLID hem beni hemde yazdığım kodu yavaşlatıyor..." vs. şeklinde yorumlar yapılmıştı. Doğrusu en başlarda bende buna benzer cümleler kurmadım değil :)
SOLID prensiplerinin asıl amacı Separation of Concerns veya türkçe deyimiyle farklı kavramların, işlerin birbirinden ayrılması ilkesini High Cohesion & Low Coupling yoluyla geliştirmek. Prensipleri anlattığımız ilk yazıda şuna benzer bir cümle kullanmıştım "asıl amaç sonradan kolay müdahale edilebilir, yeni modüllerin kolay entegre edilebildiği core code'a çok fazla dokunmadan yazılımlar geliştirmek..." ve aslında bu cümle 5 temel prensiple bizlere anlatılıyor. İlk bakışta bu prensiplerin uygulaması zahmetli gibi geliyor olabilir ancak bunu ileriye dönük iyi bir yatırım olarak görmeliyiz ve yazılım geliştirme sürecini while(true) {develop}şeklinde sonsuz bir döngü olarak bakmalıyız.
SOLID prensiplerine uyalım derken bazı istenmeyen sonuçlarortaya çıkarmamızda mümkün;
- Çok fazla abstraction ve interface,
- İstenmeyen Concrete class'lar,
- Gerektiğidnen fazla layer oluşabilme itimali,
- Kalıtım ağacıdnaki derinliği gereknden fazla artırma,
- Yo-yo problemi,
- vs...
SOLID prensiplerinin gelişi güzel uygulanması bu ve benzeri durumların olmasına neden oalbilir ancak geliştirme yaparken arada bir geriye gelip geniş açıdan bakmakta fayda var çünkü bazen oop nin dibine vurmaya çalışırken farkında olmadan saçmalamışta olabiliriz :) . Tabi burda da devreye iyi deneyime sahip, çeşitli projelerde görev almış vizyon sahibi bir takım liderine gerek var ki code-review sırasında nokta atışı yaparak yanlış veya gereksiz olan yerleri saptayıp düzeltebilme fırsatınız olsun.
SOLID yazılım süreçlerini yavaşlatıyor mu ? sorusuna geri dönecek olursak, yukarıda da bahsettiğimiz üzre çok separation of concern'ü düşünerek yapacağımız işleri çoklu katmanalra ayırarak böyle bir duruma sebebiyet verme ihtimalimiz azda olsa var. Diğer bir deyişle tek bir metot çağrısı yaparak çözebileceğimiz bir sorunu birden fazla instance alarak metot çağrısı yapmaya zorlandığımız durumlar ortaya çıkabilir ve bu da geliştirme süresini uzatabilir. Ancak SOLID prensiplerini hangi projeye uygulanması gerektiğine karar vermekte bir o kadar önemli çünkü small diyebileceğimiz projeler için dibine kadar SOLID kastırmak çokta şart değildir hani. Bunun yerine enterprise veya işlevselliği çok olan büüyk projerlerde SOLID prensiplerini uygulamaya çalışmalıyız ve unutmamalıyız ki SOLID'e uygun geliştirmeler yaparak günü kurtarmıyoruz bunu ileriye dönük bir yatırım olarak görmeliyiz ve asıl faydalarını projenin ilerleyen fazlarında görüyor olacağız.
Ben kendi projelerimde nasıl ilerliyorum diye soracak olursak, mümkün olduğunda separation of concern'e odaklanmaya çalışıyorum ve ona uygun ilerleyecek sade-temiz bir design pattern seçmeye çalışırım. Çok fazla abstraction'dan dolayı performans sorunları olacağını düşündüğüm yerler varsa da yaygın kullanılan bir runtime performans tool'u kullanarak testler yapıp sorunu saptamaya odaklanırım.
Sonuç olarak SOLID yazılım süreçlerini yavaşlatıyor mu sorusuna bence en uygun cevap, SOLID'i ne kadar doğru zamanda doğru yerde kullandığınızla ilgili. Eğer prensiplere tamamiyle hakimseniz ve doğru projede uyguladığınızı düşünüyorsanız kesinlikle yazılım süreçlerini yavaşlatmıyor aksine hızlandırıyor. Şuan için farkında olmasanız bile ileriye dönük size birçok katkı sağlayacağı noktalar olacaktır. Eğer çok gereksiz bir projede hiç ihtiyaç yokken SOLID'in dibine vurmakta tavsiye edilen bir durum olmayacaktır, çok büyük bir ihtimalle geliştirme sırasında gereksiz zaman kaybına yol açacaktır.