Tek Sorumluluk prensibi ile gelecekte yaşanabilecek karmaşaların, geliştirme ve test zorluklarının önüne geçeriz. Bu prensiple odaklanmamız gereken tek bir konu vardır; modüller, sınıflar, metodlar, fonksiyonlar vs. parçalara ayırabildiğimiz her yerde ilgili parçacığa yalnızca bir sorumluluk yüklenmeli ve sadece sorumluluk yüklenilen işi yapması beklenmelidir.
Bu sayede elimizde okunabilir, anlaşılabilir, geliştirilebilir ve test edilebilir bir kod/uygulama olacaktır. Zaten olması gerekenin de bu olduğunu düşünüp benimseyecek olursak; geliştirme yaparken sürekli aklımızın bir köşesinde bu prensibi tutmak faydalı olacaktır.
A class should have one, and only one, reason to change.
Robert C. Martin
Bir musluktan su içmenin yanı sıra evinizde aydınlatmasını beklerseniz karşınıza çok farklı üretim, bakım ve kullanım sorunları çıkacaktır. Bunun yerine musluktan sadece su içmeli, evinizi aydınlatması için haricen bir ampül kullanmalısınız. Musluğa ayarlanabilir şekilde suyu açıp kapatması dışında sorumluluk yüklememelisiniz.
Peki ama bunu nasıl yapıyoruz, yapmalıyız soruları kafanızda canlandıysa konuyu pekiştirmek için okumaya devam edebilirsiniz.
Metodlar üzerinden konuyu biraz daha anlamlandıracak olursak; birden fazla sorumlulukları olsa ne olur ki?
User sınıfımızın içerisinde yalnızca Update adında bir metodumuzun olduğunu ve bu metod içerisinde if/else ile yapılacak eylemlere karar verdiğimizi farzedelim. Bu durumda e-posta, kullanıcı adı ya da şifre güncellemesi için elimizde tek bir metod olacak. Yani koda dökmek gerekirse aşağıdaki gibi bir sınıfa sahip olacağız.
Eğer phone adında bir alanımız daha olsa bu metoda ek yapıp phone alanının güncellenmesine dair olacak işlevleride Update metodu içerisine yazıyor olacağız. Haliyle her güncellenebilecek alan için bu metoda yeni bir değişken ve metod gövdesine de ilgili betikleri yazmamız gerekiyor. Yani bu durumda uzun ve uzayacak hatta uygulamanın geliştirilmesi esnasında da gövdesi sürekli büyüyen kötü bir metodumuz olacak.
Böyle olsa ne olur? Başımıza ne işler gelir?
Metod çok uzun olacağından hem kodu yazan hemde okumak durumunda kalan başkaları için anlaşılabilirlik bakımından zorluklar oluşacaktır.
Olası bir hata durumunda diğer işlevlerin etkilenmesi kuvvetle muhtemeldir. (Örneğin; username güncellerken bir exception fırlasa ya da birisi dalgınlıkla bir condition içerisinde return result; yazsa kullanıcı adı güncelleme işlevlerinden sonrasındaki kod bloğu çalışmayacaktır.)
En önemli bir başka nokta ise böyle bir metodu test etmek bu prensibin dikkate alınarak yazıldığı bir metoda göre çok daha zor olacaktır.
Olması Gerektiği Hali
Hatta eğer User sınıfımız daha büyürse ya da büyükse UserAction sınıfına taşıyarak, User sınıfında UserAction’u extend etmeli, bu sayede sınıf gövdesinin uzamasını engellemeli ve olabildiğince mantıklı parçalara ayırmalıyız.
