Single Responsibility (SRP) Prensibi

single responsibility prensibi

Her modül, sınıf veya fonksiyon yalnızca tek bir işlevi yerine getirmeli ve tek bir amacı olmalıdır. Amaçla ilişkili olduğu sürece sınıf içerisinde bir çok üye olabilir ve sorumluluk bir sınıf tarafından kapsüllenmelidir. Single responsibility prensibi uygulanarak kodumuz daha atomik ve temiz olmakla birlikte daha az kırılgan (Fragility) olmaktadır.

A class should have only one reason to change. (Bir sınıfın değişmesi için tek bir nedeni olmalıdır.)

Robert C. Martin

Şimdi bu prensibi bir örnekle pekiştirelim. Buna göre kullanıcı kayıt ve giriş işlemlerini yöneten bir uygulamaya ihtiyacımız olduğunu düşünelim. Uygulamamız aynı zamanda giriş ve kayıt işlemleri sonrasında kullanıcıya bilgilendirme amaçlı e-posta gönderecek ve olası bir hata durumunda loglama da yapacaktır. Hemen işe koyulup aşağıdaki kodu yazdığımızı düşünelim.

Kodumuzu incelediğimizde e-posta gönderme ve loglama işlemlerinin kullanıcı ile bir ilişkisi olmadığını görüyoruz. Ayrıca uygulama içerisinde kullanıcı arayüzünü çağıramadığımız ya da çağırmanın mantık dışı olduğu senaryolarda uygulamanın başka bir yerinde e-posta gönderme ve loglama yapmak istediğimizde aynı kodu tekrar yazmamız gerekecek ve DRY prensibini ihlal etmiş olacağız; bununla birlikte aynı işi yapan iki fonksiyon olduğunu düşünün ve birinde modifikasyon yapıp diğerini unuttuğumuzu…

Single responsibility prensibi uygulayarak kodumuzu uygun hale getirelim.

Artık tüm arayüzlerimiz tek bir amaca hizmet ederek kendi işlerini gerçekleştirecek sınıflar tarafından implemente edilmeye hazır. Bu sayede ortaya yönetimi ve tekrar kullanılabilirliğini (Reusability) artmış bir yapı çıkmıştır.

Clean Code ile ilgili ufak bir not

Bu konuya burada değinmeden bitirmek istemiyorum. Yukarıda oluşturduğumuz 3 arayüze tekrar göz atalım; hala ufak bir sıkıntı var. Arayüzleri implemente ettiğimizi; kullanıcı giriş ve kayıt işlemleri ve de bir hata yakalandığında e-posta gönderdiğimizi düşünelim.

IEmailService.SendMail fonksiyonuna başlık alanı eklemek istiyoruz. Bu işlemi yaptığımızda bu fonksiyonu nerelerden kaç kere çağırıyorsak hepsini teker teker düzeltmemiz gerekecek. Bu da bir hayli ve yorucu bir iş, özellikle kurumsal büyük projelerde. Kaldı ki bu maliyeti göz önüne alsak bile 50 parametresi olan bir fonksiyon düşünün ve gözlerimizin kanamaya başladığını…

Hemen kodumuzu parametrik açıdan değişikliklere açık ve daha okunabilir hale getirelim.

Artık modellerimizi oluşturduğumuza göre arayüzlerimizi de değiştirebiliriz.

You may also like...

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.