Single Responsibility (SRP) Prensibi

single-responsiblity-prensibi

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

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. Bu prensiple birlikte kodumuz daha atomik ve temiz olmakla birlikte daha az kırılgan (Fragility) olmaktadır. Şimdi bu prensibi bir örnekle pekiştirelim.

Örneğin: 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…

Kodumuzu prensibimize uygun hale getirelim.

Artık tüm arayüzlerimizin tek bir amacı var ve kendi işlerini gerçekleştirecek sınıflar tarafından implemente edilmeye hazır. 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.