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.579 yükleme)
EOF (End of Fun)
Özcan Acar
Tasarım Prensipleri kategorisinden son yazılar
- Sorumluluk Sahibi Olmak - August 20th, 2012
- SOLID - December 30th, 2011
- Stable Abstractions Principle (SAP) – Stabil Soyutluk Prensibi - October 26th, 2011
- Stable Dependencies Principle (SDP) – Stabil Bağımlılıklar Prensibi - October 26th, 2011
- Acyclic Dependency Principle (ADP) – Çevrimsiz Bağımlılık Prensibi - October 26th, 2011
- Common Closure Principle (CCP) – Ortak Kapama Prensibi - October 26th, 2011
- Common Reuse Principle (CRP) – Ortak Yeniden Kullanım Prensibi - July 24th, 2010
- Reuse-Release Equivalence Principle (REP) - Tekrar Kullanım ve Sürüm Eşitliği - December 9th, 2009
- Interface Segregation Principle (ISP) – Arayüz Ayırma Prensibi - November 17th, 2009
- Dependency Inversion Principle (DIP) - Bağımlılıkların Tersine Çevrilmesi Prensibi - October 29th, 2009
Pingback: Metodu Metot Nesnesine Dönüştürme (Replace Method with Method Object) - Kurumsal Java Yazılımı
Pingback: Yeni Sınıf Oluşturma (Extract Class) - Kurumsal Java Yazılımı
Pingback: SOLID - Kurumsal Java Yazılımı
Ceydaa_Gunactii
30 Ocak 2012Herkese 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…
Pingback: Programcılar yazar olsalardı keşke! - Kurumsal Java Yazılımı
Pingback: Her Programcı Kendisini İspatlamak Zorundadır - Kurumsal Java Yazılımı - Özcan Acar
Pingback: Test Güdümlü Geliştirmenin Etkileri | Ömer ÖZKAN
Pingback: Pratik Programcı Yayınları » Spring Çatısının Yazılım Geliştirme Filozofisi
Pingback: Pratik Programcı Yayınları » PHP Uygulamaları Nasıl Hızlandırılır? FastCGI, PHP-FPM ve OpCache Kullanımı
Pingback: Pratik Programcı Yayınları » Sözde Lean!
Pingback: Pratik Programcı Yayınları » Programcının Hayatını Kolaylaştıran 18 Alışkanlık
Pingback: PHP Uygulamaları Nasıl Hızlandırılır? FastCGI, PHP-FPM ve OpCache Kullanımı | Berkehan Bendivar