SOLID bir sınav konusu değil, bakım kolaylığı meselesi
SOLID prensipleri ilk duyulduğunda biraz akademik geliyor. Single Responsibility, Open Closed, Liskov derken insan “tamam da ben bugün admin panelde servis kaydı düzenleyeceğim” diye düşünüyor. Haklı. Ama mesele prensip isimlerini ezberlemek değil, kod büyüdüğünde kendimize alan açmak.
Single Responsibility en çok nerede işe yarar?
Bir controller hem validasyon yapıyor, hem dosya yüklüyor, hem veritabanına yazıyor, hem de mail gönderiyorsa burada sorumluluklar karışmış demektir. Bunu ayırınca test yazmak da okumak da kolaylaşır. Controller isteği alır. Request doğrular. Service işi yapar. Gerekirse repository veri tarafını toparlar.
Open Closed günlük hayatta nasıl görünür?
Diyelim ki teklif hesaplama sisteminiz var. Her yeni seçenek geldiğinde eski hesaplama kodunun ortasına if ekliyorsanız bir süre sonra hesap makinesi değil, mayın tarlası olur. Bunun yerine seçenek tiplerini ayrı sınıflara veya daha net stratejilere ayırmak, yeni özellik eklemeyi daha güvenli hale getirir.
Interface kullanmak moda diye yapılmaz
Interface kullanmanın amacı havalı görünmek değil. Gerçekten iki farklı uygulama ihtimali varsa, testte sahtelemek istiyorsanız veya bağımlılığı gevşetmek istiyorsanız anlamlıdır. Yoksa her sınıfa interface açıp projeyi kalabalıklaştırmak da başka bir dert.
- Önce kodun neden değiştiğini izleyin.
- Sürekli değişen yerleri daha küçük parçalara bölün.
- Her soyutlamayı değil, işe yarayan soyutlamayı kullanın.