Tek Sorumluluk Prensibi S.O.L.I.D prensiplerinden biridir. Bir yazılım modülünün (sınıfın, metodun, fonksiyonun, arayüzün, algoritmanın) sadece tek bir sorumluluğu olması fikrini ön plana çıkartır. Bu ifadeyi tersten okuduğumuzda bir yazılım modülü, sadece tek bir nedenden dolayı değiştirilebilir olmalıdır sonucuna erişebiliriz.
Yazılım birimi, finans birimi, IK birimi olan bir kurumda kullanılan yazılım uygulamasında aşağıdaki sınıf tasarımı olduğunu varsayalım.
Employee sınıfı, yazılım temel katmanında (domain) modellediği varlığın (soyut ya da somut) özelliklerini sunan bir model sınıf olması gerekirken, sanki servis katmanındaki bir sınıf gibi duruyor. Model ve servis sorumlulukları iç içe girmiş gibi gözüküyor. Bu durumu düzeltmek adına temel katmanda Employee model sınıfı varmış gibi düşünüp yukarıdaki sınıfın ismini ve metodlarını aşağıdaki gibi değiştirip tekrar ele alalım.
Servise çalışan maaş hesaplaması, mesai raporlama ve özlük bilgisi saklama sorumluluklarının
yüklenmiş olduğu bilgisi sunduğu metodlardan görülebilmektedir.
IK birimi, maaş hesaplamasında iş kurallarını değiştirdiğinde servis değişime gidecektir. Departmanlardan herhangi biri yeni bir rapor ya da raporlamalarda farklılık istediğinde servis değişecektir. Özlük bilgilerinde veya veritabanı şemalarında değişim olduğunda servis değişecektir.
Bu değişimleri yazılım birimi nasil el alacaktır ?
Aynı anda aynı yazılım modülünde çalışmak durumuna düşmeyecekler midir ?
Bütün yollar Roma' ya çıkabilir ama farklı neden ve sorumluluklarla açılan değişimler aynı yazılım modülüne çıkıyor ise tasarım hatası yapıyor ve sanırım Nero' nun izinden gidiyoruz demektir.
Yukarıdaki servisi tek bir sorumluluk alacak şekilde tekrar düzenleyelim.
Tek sorumluluk prensibine sadık kalmak amacı ile servis sınıfları (Facade tasarım kalıbı), servis katmanında sorumluluklarına göre ayrıldı. Ayrıca sistemin bütününe girmeden tek bir noktadan kullanıcıya bu servisler EmployeeServis sınıfı üzerinden sunuldu (Yine Facade).
Fakat prensip ihlali devam etmekte. Bütün sınıflar tek bir (.cs) dosyası içine koyulmuş. (.cs) dosyasına birden fazla neden ile gitme ve değişim yapmak söz konusu olmakta. Ayrıca EmployeeServis sınıfı sorumluluklarını diğer sınıflara dağıtmış ama hangi sınıflarla çalışacağını bilmek ve onları oluşturmak görevini almak durumunda kalmış. En azından sorumluluğu dağıttığı diğer sınıfların ismi değişse bu EmployeeServis sınıfında da değişime neden olacak. Bahsedilen bulgulara göre tekrar düzenleme yapalım.
Aşağıda EmployeeServis sınıfı, son kullanıcının kullanımına açtığı diğer sınıflarla iletişimini arayüzler üzerinden yapmaktadır. İşlevi bilmekte ama bu işlevi yerine getiren öznenin kendisini bilmemektedir. Diğer sınıfların dağılımını sizlere bırakmaktayım.
Görüldüğü üzere prensip sadece kod bazında değil organizasyon bazında da kullanılmaktadır.
Çok katmanlı yazılım mimarisi denildiğinde sizce bu prensip orada da kendini göstermekte midir ?
Cevabı size bırakıyorum.
Hiç yorum yok :
Yorum Gönder