Merhabalar, bu yazımda bir önceki yazımda SOLID kısaltmasıyla bahsetmiş olduğum Tasarım Prensiplerinden, SOLID'in ilk harfi olan S 'yi ifade eden "Single Responsibility Principle" den bahsediyor olacağım.
Tek Sorumluluk Prensibi olarak nitelendirilen SRP adından da anlaşılacağı gibi bir sınıf veya metodun tek bir görev/sorumluluğunun olması gerektiğini belirtmektedir. SRP bize açık bir şekilde, bir sınıf veya metodun değiştirilebilmesi için tek bir sebebinin bulunması gerektiğini izah etmektedir. Birden fazla görev veya sorumluluk yerine getiren metod veya sınıfların değiştirilmeye açık birden fazla sebepleri olacak, bu da zamanla kodda karmaşıklık ve olası hata ihtimalini çoğaltacaktır. Teoride bu şekilde açıkladığımız olay, elbette projelerimizde gerek zaman darlığından, gerekse de SRP' ye dikkat edilmediğinden bir metod veya sınıfın birden fazla işi yerine getireceği şekilde dizayn edilmektedir. Bu tasarlayacağımız dizaynda sınıf veya metodların birbirine olan bağlılıkları düşünüldüğünde zaman içerisinde yapılacak herhangi bir fonksiyonel değişikliğin, bağlı diğer yapılardaki fonksiyonellikleri ne derecede etkileyeceğini ön görmemiz neredeyse imkansızdır ve buda hemen hemen tüm sürecin en baştan bütünüyle test edilmesini gerektirecektir. Bunu yapabilecek otomatik test programlarımızın olduğunu varsaysak bile ( ki çoğu yazılım firmasında dahi yok), çıkacak hataları çözmek ve süreci sorunsuz atlatmak için ne kadar iş gücüne ihtiyacımız olduğunu göz önünde bulundurmanız gerekmektedir.
Durumu örneklendirmemiz gerekirse aşağıdaki gibi hem promosyonları hesaplayan hem de fatura kaydeden bir metodumuz olduğunu düşünelim;
"PromosyonHesaplaFaturaKes" metodunun yaptığı 2 iş olduğundan, bu metodu değiştirmek için 2 farklı ana sebep hatta bunlara bağlı onlarca yan sebep olacaktır. Bu kesinlikle istenmeyen bir durumdur, ayrıca bu metod işlev olarak başka yerlerde kullanılmaya uygun değildir. Promosyon hesapları sürekli değişebileceğinden aynı metod muhtemelen başka hiç bir yerde kullanılamayacaktır. Bu yüzden bunları ayırıp aşağıdaki şekilde 2 parçaya bölmemiz gerekecektir.
Hatta ve hatta yapısal olarak promosyon hesabı sipariş ve irsaliyede de olabileceğinden ve yine promosyon hesaplama işleminin fatura kesme işleminden çok farklı bir işlevi olduğundan, bu metodlar ayrı sınıfların üyesi olarak yazılmalıdırlar. Son hali aşağıdaki gibi olan bir yapıda Promosyon hesaplamada bir hata varsa veya bir değişiklik isteniyorsa nereye bakacağımız bellidir. Tek bir işlevi olan "PromosyonHesapla" metodundaki değişiklik programa dinamizm kazandıracak, ayrıca birden fazla yerde (sipariş, irsaliye,fatura vs) kullanılabilecektir.
Yazılan ilk hatalı yapıdaki gibi farklı farklı işleri yapan metodları maalesef çoğu zaman aynı sınıfın içine yazıyoruz ( dolduruyoruz desek daha mantıklı). Bu tip durumlarda satır sayısı 5000 'leri bulan sınıflarımız oluyor. Düşünün ki 5000 satırlık bir sınıf, ne işler yapıyordur, neler neler barındırıyordur içinde. Entegrasyonundan tutun, loglamaya hatta sisteme login logout olmaya kadar her işi defalarca yapan sınıflar hayal edebilirsiniz, etmeyin :) Ayrı görevi ve sorumlulukları olan ayrı sınıflar ve metodlar hayal edin, tıpkı bir insanın hem doktor hem mühendis olamayacağını ve bunların ayrı görev sorumlulukları olduğu gibi. Hatta biraz daha irdeleyin doktor ve mühendisi ayırdıktan sonra bunları da kendi içinde ayırma yoluna gidin; göz doktoru, cerrah, kbb doktoru gibi...Unutmayın ki eğer yazdığınız metodlar 30-35 satırı, sınıflar da 1000 satırı geçiyorsa yaptığınız işte bir yanlışlık vardır :) Yazılan kodların mutlaka tekrar gözden geçirilmesi ve mümkün mertebe farklı işler yapan daha küçük parçalara ayrılması gerekmektedir.
Programı yazarken, tasarlarken mümkün mertebe bu şekilde düşünerek en dibe inmeye çalışın. Ayrı işlevi olan bölümleri kesinlikle ayrı ve olabildiğince özel işler yapan kısımlara ayırın ki program esnek olsun, aynı zamanda kırılganlık ve bağımlılığı düşük olsun.Unutmayın ki 100 küsür satırdan oluşan bir metodun değiştirilmesi veya hata düzeltmesi bir yana, daha küçük parçalara bölünmüş 15 satırlık metodun değiştirilmesi bir yanadır.
Unutulmaması gereken bir konu SRP 'nin teoride kolay, fakat pratikte uygulamanın hiç de öyle olmadığıdır. Programın nerede küçük kısımlara ayrılması gerektiği kodu yazarken tamamen kestirilememektedir. O yüzden bu işlem ilk başlarda uygulanması çok zor bir yöntemdir.Bir bakışta programı parçalara bölmek tecrübe gerektiren bir iştir, fakat üstte yaptığımız gibi kodlar yazıldıktan sonra tekrar tekrar üstünden geçerek düzeltilip SRP 'ye uygun hale getirilebilir ki biz buna Kod Gözden Geçirme (Refactoring) diyoruz, buradan bu bilgiyi de vermiş olalım :)
Örnek :
Şimdi ki örneğimizde çok basit bir web sayfası tasarlayıp, input olarak aldığı bilgiyi müşteri bakiyesi ile kontrol ederek yeterli bakiye varsa, db ye kayıt atıp müşteriye de mail gönderen bir tasarım gerçekleştirelim.
Yukarıdaki örnek işlevsel olarak sadece 1 görev/sorumluluk üstlenen farklı metodlara bölünmüş olmasına rağmen, birbirinden çok farklı işler yapan bu metodların aynı sınıf içinde yer alması dolayısıyla SRP dizaynına uymamaktadır. Projemizi SRP'ye uygun hale getirmek için Refactoring yaparak, Mail gönderimi ve Müşteri Bakiye Kontrol işlemini ayrı sınıflara alıp tekrar aşağıdaki gibi yazmamız gerekmektedir.
Projemizde farklı işler yapan metodları farklı sınıflara ayırdıktan sonra, hem esneklik hem de kullanılabilirliği sağlamış olduk. Hatta bir adım daha öteye giderek, mail gönderme ve limit sorgulamanın çok genel bir yapı olduğunu göz önüne alarak, projeye isimlendirme standartlarına da uyarak "SRP.Core" diye bir class library ekleyip sınıflarımı, katmanları da birbirinden ayırmış olduğum "SRP.Core" içerisine ekliyorum ve yeni tasarımım aşağıdaki hale geliyor.
Yapıyı bu şekilde oluşturduktan sonra artık farklı projelere referans verilebilir hale getirmiş bulunmaktayım.Şu durumda sadece "SRP.Core" library projesini başka projelere referans vermemiz ortak kullanabilmek adına yeterli olacaktır, aksi durumda koskoca web projesini referans göstermek zorunda kalacaktık ki, bu durumda ne esneklik ne de modülerlikten bahsedebiliriz. Fakat son durumda katmanları ayırarak hem katmanlı ve modüler bir mimari, hem de SRP 'ye uygun dizaynı gerçekleştirip bir taşla iki kuş vurmuş olduk.
Böylece SOLID prensiplerinden ilki olan SRP' yi oldukça basit bir şekilde anlatmaya çalıştım, bir sonraki yazım olacak olan "Open/Closed Principle" ile görüşmek üzere.
