Single Responsibility Principle (SRP) – Tek Sorumluk Tasarım Prensibi

Eki 14th, 2009 | Yazar: Özcan Acar | Kategori: Tasarım Prensipleri

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, 2.913 yükleme)


EOF (End of Fun)
Özcan Acar

Share Button

Özcan Acar

Bilgisayar mühendisi olan Özcan Acar 1997 yılından beri programcı olarak çalışıyor.

KurumsalJava.com, SmartHomeProgrammer.com ve Mikrodevre.com adresleri altında blog yazıyor. Kurduğu BTSoru.com'da ona yazılımla ile ilgili sorularınızı yöneltebilirsiniz. Pratik Programcı Yayınları bünyesinde Pratik Spring, Pratik Agile, Pratik Git ve Design Patterns ismini taşıyan kitapları bulunmaktadır. 21.12.2009 tarihinde Java Champion olarak seçildi.
  • Share/Bookmark
12 yorum | 8.487 kez okundu |

1 Yıldız2 Yıldız3 Yıldız4 Yıldız5 Yıldız (3 değerlendirme, ortalama: 3.67, toplam oy 5)
Loading ... Loading ...

12 YORUM “Single Responsibility Principle (SRP) – Tek Sorumluk Tasarım Prensibi”

  1. […] SRP tasarım prensibi ile uyumlu degil yani refactor etmek istedigimiz metot, bünyesinde bulundugu […]

  2. […] ana sebeplerinden birisi bu sınıfa birden fazla sorumluluğun yüklenmiş olmasıdır. Single Repsonsiblity (SRP) prensibinden de bildigimiz gibi her sınıfın sadece ve sadece bir sorumluluk alanı olmalıdır […]

  3. Ceydaa_Gunactii diyor ki:

    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…

  4. […] metotlar en fazla dört satırdan oluşuyor. Her sınıfın ve metodun sadece bir sorumluğu (SRP) var. Sınıf, metot ve değişken isimlerini çok özenle seçiyoruz. Kesinlikle bir kod […]

  5. […] önce de bahsettiğim gibi kodun özenli yazılmış, her sınıfın sadece bir sorumluluğu sahip (SRP prensibi), diğer SOLID prensipleri ile uyumlu, otomatik çalışan unit testlerine sahip, değişken ve […]

  6. […] yaptığını ve bir sorumluluk daha yüklediğimi farkettim. Bu da önemli prensiplerden birini “Single Responsibility” yani “Tek Sorumluluk” prensibini daha önce defalarca ihlal ettiğim anlamına […]

  7. […] yönetmek zorunda olmayan bir sınıf asıl işi olan işletme mantığına konsantre olabilir. Tek sorumluluk prensibi açışından bakıldığında da bu bir […]

  8. […] kullanıcıya göndermek, bir koltuk altında iki karpuz taşımak gibi bir şeydir. Bu tek sorumluluk prensibine aykırı olan bir durumdur. Her modülün tek bir sorumluluk alanı […]

  9. […] sınıf tek sorumluluk prensibine çok aykırı bir yapıda. Bu sınıfın en az dört değişik sorumluluğu bulunuyor. Bu sınıf […]

  10. […] yönelik programlamada sınıf ve metotların çok uzun olmalarının başlıca sebebi, kodun tek sorumluluk prensibine sadık kalınarak, geliştirilmemiş […]

  11. […] kullanıcıya göndermek, bir koltuk altında iki karpuz taşımak gibi bir şeydir. Bu tek sorumluluk prensibine aykırı olan bir durumdur. Her modülün tek bir sorumluluk alanı […]