Resim 1 deki gibi bir sınıfa daha önce bir yerlerde rastlamışsınızdır. Bu sınıf kendisini bilgibankasına ekleme, silme, müşteriye email gönderme, login yapma (shop sistemi olabilir) ve sipariş oluşturma işlemlerini yapabilmektedir.
Resim 1
Büyük bir ihtimalle bu sınıfı programlayan programcı kendisi ile gurur duyuyor olmalıdır. Aslında böyle bir sınıfın ve programcının küçümsenecek hiçbir tarafı yok. Bu sınıf büyük emek harcanarak oluşturulmuş olabilir, çünkü ihtiva ettiği metotlar basit değildir. Lakin bu sınıf saatli bir bombadır, çünkü içinde bulunduğu ortamdaki her değişiklik, sınıfın yapısal değişikliğe uğramasına sebep olabilir. Bunun yanı sıra Customer sınıfında implemente edilen kod tekrar kullanılmak istendiğinde, Customer sınıfının bağımlı olduğu sınıf ve API’lerin bu sınıfla beraber kullanılma zorunluluğu vardır, yani Customer sınıfı gittiği yere beraberinde kullandığı diğer sınıflar ve API’leri götürür. Bu kodun tekrar kullanımını sağlamak için istenmeyen bir durumdur.
Customer sınıfını test edilebilir ve bakımı kolay bir hale getirmek için, sahip olduğu sorumlulukların başka sınıflara yüklenmesi gerekmektedir. Bunun bir örneğini resim 2 de görmekteyiz.
Resim 2
Resim 2 de yer alan Customer sınıfı sahip olduğu sorumlulukların başka sınıflara yüklenmesiyle hafiflemiş ve değişikliklere karşı daha dayanıklı bir hale gelmiştir. Bunun yanı sıra bu sınıfın test edilebilirliği yükselmiştir. Bu ve diğer sınıfların değişmek için artık sadece bir sebebi vardır. Bunun sebebi sadece bir sorumluluk sahibi olmalarında yatmaktadır.
Bir sınıfın sorumluluğunu sadece bir sebepten dolayı değişebilir olması olarak tanımlayabiliriz. Eğer bir sınıfın değişikliğe uğraması için birden fazla sebep varsa, bu sınıf birden fazla sorumluluk taşıyor demektir. Bu durumda sınıfta sadece bir sorumluluk kalacak şekilde, sorumlukların diğer sınıflarla paylaşılması yoluna gidilmelidir.
Bu yazıyı PDF dosyası olarak aşağıdaki linkten edinebilirsiniz.
Single Responsibility Principle (SRP) - Tek Sorumluk Tasarım Prensibi (32,3 KiB, 6.719 yükleme)
EOF (End of Fun)
Özcan Acar
Geri izleme: Metodu Metot Nesnesine Dönüştürme (Replace Method with Method Object) - Kurumsal Java Yazılımı
Geri izleme: Yeni Sınıf Oluşturma (Extract Class) - Kurumsal Java Yazılımı
Geri izleme: SOLID - Kurumsal Java Yazılımı
Herkese Merhaba
Bu platform oldukça yararli bilgiler içeriyor. Siteniz google reader’a ekledim vakit buldukça takip etmeye çalisacagim. Soru ve cevaplarla siteye katkida bulunmak isterim.
Kolay gelsin…
Geri izleme: Programcılar yazar olsalardı keşke! - Kurumsal Java Yazılımı
Geri izleme: Her Programcı Kendisini İspatlamak Zorundadır - Kurumsal Java Yazılımı - Özcan Acar
Geri izleme: Test Güdümlü Geliştirmenin Etkileri | Ömer ÖZKAN
Geri izleme: Pratik Programcı Yayınları » Spring Çatısının Yazılım Geliştirme Filozofisi
Geri izleme: Pratik Programcı Yayınları » PHP Uygulamaları Nasıl Hızlandırılır? FastCGI, PHP-FPM ve OpCache Kullanımı
Geri izleme: Pratik Programcı Yayınları » Sözde Lean!
Geri izleme: Pratik Programcı Yayınları » Programcının Hayatını Kolaylaştıran 18 Alışkanlık
Geri izleme: PHP Uygulamaları Nasıl Hızlandırılır? FastCGI, PHP-FPM ve OpCache Kullanımı | Berkehan Bendivar