Tek sorumluluk ilkesi

Vikipedi, özgür ansiklopedi


Tek sorumluluk ilkesi (TSİ), "Bir birimin sadece bir etkene karşı sorumlu olması gerektiği" şeklinde bir bilgisayar programlama ilkesidir. Etken terimi, birimde değişiklik gerektiren bir küme (en az bir paydaş veya kullanıcıdan oluşan) için kullanılır.

Terimin yaratıcısı Robert C. Martin ilkeyi, "Bir sınıfın değişmek için bir tek nedeni olmalıdır" şeklinde ifade eder.[1] "Neden" deyişindeki karışığa "ilke, insanlarla ilgilidir" diyerek açıklık getirdi.[2] Bazı konuşmalarında bu ilkenin, özellikle görevler veya etkenler hakkında olduğunu da savunuyor. Örneğin, aynı kişi olabilseler de bir saymanın görevi, bir veri tabanı yöneticisininkinden ayrıdır. Bu nedenle her bir görevden bir tek birim sorumlu olmalıdır.[3]

Tarihçe[değiştir | kaynağı değiştir]

Terim, Robert C. Martin tarafından "NYT'nin İlkeleri" makalesinde tanıtılmıştır. Bu, 2003 yılında yayınlanan Atik Yazılım Geliştirme, İlkeler, Desenler ve Uygulamalar kitabıyla yaygın hale gelen Nesne Yönelimli Tasarımın İlkeleri[4] bölümünün bir parçasıdır.[5] Martin, Tom DeMarko'nun Yapılandırılmış Çözümleme ve Düzen Özelleştirme[6] kitabında ve Meyir Pajcons'un Yapılandırılmış Düzenlerin Tasarımına İlişkin Uygulamalı Rehber[7] kitabında açıkladığı gibi tutarlılık ilkesine dayandığını açıklamıştır. 2014 yılında, Martin, değişiklik nedeni ifadesinin ne anlama geldiğini açıklamak için "Tek Sorumluluk İlkesi" adlı bir ağ günlüğü yazısı yayınladı.[1] 17 Aralık 2022 tarihinde Wayback Machine sitesinde arşivlendi.

Örnek[değiştir | kaynağı değiştir]

Martin; sorumluluğu, değişiklik sebebi olarak tanımladı ve bir sınıfın veya birimin değiştirilmesi (örneğin yeniden yazılması) için bir tek sebep olması gerektiği sonucuna vardı.

Örneğin, bir yazanağı derleyip yazdıran bir birimi ve bu birimin de iki nedenle değiştirilebileceğini düşünün. İlk olarak, yazanağın içeriği değişebilir. İkincil olarak, yazanağın biçimi değişebilir. Bu iki şey farklı nedenlerle değişir. Tek sorumluluk ilkesi, bu iki sorunun, iki ayrı sorumluluk olduğunu ve bu nedenle de ayrı sınıflarda veya birimlerde olması gerektiğini söyler. Farklı nedenlerle, farklı zamanlarda değişen iki şeyi birbirine bağlamak kötü bir tasarım olur.

Bir sınıfı tek bir etkene odaklamanın önemi, sınıfın daha dayanıklı hale getirilmesidir. Önceki örnekle devam edersek, yazanak derleme işleminde bir değişiklik olursa, aynı sınıftaki yazdırma kodu daha yüksek olasılıkla bozulur.

Kaynaklar[değiştir | kaynağı değiştir]

  1. ^ Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. 2003. s. 95. ISBN 978-0135974445. 
  2. ^ "The Single Responsibility Principle". The Clean Code Blog. 2014. 6 Şubat 2017 tarihinde kaynağından arşivlendi.  Yazar |ad1= eksik |soyadı1= (yardım)
  3. ^ Robert C. Martin (2018). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. ISBN 978-0-13-449416-6. 17 Aralık 2022 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Aralık 2022. 
  4. ^ Martin, Robert C. (2005). "The Principles of OOD". butunclebob.com. 17 Nisan 2006 tarihinde kaynağından arşivlendi. 
  5. ^ Martin 2003, ss. 95-98
  6. ^ DeMarco, Tom. (1979). Structured Analysis and System SpecificationÜcretsiz kayıt gerekli. Prentice Hall. ISBN 0-13-854380-1. 
  7. ^ Page-Jones, Meilir (1988). The Practical Guide to Structured Systems Design. Yourdon Press Computing Series. s. 82. ISBN 978-8120314825.