مبدأ المسؤولية الواحدة

📅 آخر تحديث: ١ أغسطس ٢٠٢٦
✍️ نُشر في: ١ أغسطس ٢٠٢٦
الموسوعة الحرة

مبدأ المسؤولية الواحدة ( SRP ) هو مبدأ برمجة حاسوبية ينص على أن "الوحدة البرمجية يجب أن تكون مسؤولة أمام جهة فاعلة واحدة فقط". [ 1 ] يشير مصطلح الجهة الفاعلة إلى مجموعة (تتكون من واحد أو أكثر من أصحاب المصلحة أو المستخدمين) تتطلب تغييرًا في الوحدة البرمجية.

يُعبّر روبرت سي. مارتن ، مُبتكر هذا المصطلح، عن المبدأ بقوله: "ينبغي أن يكون لكل فئة سبب واحد فقط للتغيير". [ 2 ] ونظرًا للالتباس الذي اكتنف كلمة "سبب"، أوضح مارتن لاحقًا معناه في مقالٍ على مدونته بعنوان "مبدأ المسؤولية الواحدة"، حيث أشار إلى فصل الاهتمامات ، وذكر أن "صياغة أخرى لمبدأ المسؤولية الواحدة هي: اجمع الأشياء التي تتغير لنفس الأسباب، وافصل الأشياء التي تتغير لأسباب مختلفة". [ 3 ] وفي بعض محاضراته، يُجادل أيضًا بأن المبدأ يتعلق، على وجه الخصوص، بالأدوار أو الجهات الفاعلة. فعلى سبيل المثال، على الرغم من أنهما قد يكونان الشخص نفسه، إلا أن دور المحاسب يختلف عن دور مدير قاعدة البيانات. وبالتالي، ينبغي أن تكون كل وحدة مسؤولة عن كل دور. [ 4 ]

تاريخ

صاغ روبرت سي. مارتن هذا المصطلح في مقالته "مبادئ التصميم الموجه للكائنات" ضمن كتابه " مبادئ التصميم الموجه للكائنات " ، [ 5 ] والذي اشتهر بفضل كتابه الصادر عام 2003 بعنوان " تطوير البرمجيات الرشيقة: المبادئ والأنماط والممارسات" . [ 6 ] وصف مارتن هذا المصطلح بأنه قائم على مبدأ التماسك ، كما وصفه توم ديماركو في كتابه "التحليل الهيكلي ومواصفات النظام" ، [ 7 ] وميلير بيج-جونز في "الدليل العملي لتصميم الأنظمة الهيكلية" . [ 8 ] في عام 2014، نشر مارتن مقالًا على مدونته بعنوان "مبدأ المسؤولية الواحدة" بهدف توضيح المقصود بعبارة "سبب التغيير". [ 9 ]

مثال

يعرّف مارتن المسؤولية بأنها سبب للتغيير ، ويخلص إلى أن الفصل أو الوحدة يجب أن يكون لها سبب واحد فقط للتغيير (مثل إعادة الكتابة).

على سبيل المثال، لنفترض وجود وحدة برمجية تُجمّع وتطبع تقريرًا. تخيّل أن هذه الوحدة قابلة للتغيير لسببين: أولًا، قد يتغير محتوى التقرير، وثانيًا، قد يتغير تنسيقه. يتغير هذان الأمران لأسباب مختلفة. ينص مبدأ المسؤولية الواحدة على أن هذين الجانبين من المشكلة هما في الواقع مسؤوليتان منفصلتان ، وبالتالي يجب أن يكونا في فئات أو وحدات برمجية منفصلة. سيكون من سوء التصميم ربط أمرين يتغيران لأسباب مختلفة وفي أوقات مختلفة.

تكمن أهمية تركيز الفئة على جانب واحد في جعلها أكثر متانة. وبالعودة إلى المثال السابق، إذا طرأ تغيير على عملية تجميع التقارير، يزداد خطر تعطل كود الطباعة إذا كان جزءًا من نفس الفئة.

انظر أيضاً

مراجع

  1. ↑ مارتن، روبرت سي. (2018). الهندسة المعمارية النظيفة  : دليل حرفي لهيكلة وتصميم البرمجيات . بوسطن. ISBN 978-0-13-449432-6. OCLC 1003645626 . {{cite book}}: CS1 maint: موقع الناشر مفقود ( رابط )
  2. ↑ مارتن، روبرت سي. (2003). تطوير البرمجيات الرشيقة: المبادئ والأنماط والممارسات . برنتيس هول. ص 95. ISBN  978-0135974445.
  3. ↑ مارتن، روبرت سي. (2014). "مبدأ المسؤولية الواحدة" . مدونة الكود النظيف .
  4. ↑ روبرت سي. مارتن (2018). العمارة النظيفة: دليل الحرفي لهيكلة وتصميم البرمجيات . برنتيس هول. ISBN 978-0-13-449416-6.
  5. ↑ مارتن، روبرت سي. (2005). "مبادئ التصميم الموجه للكائنات" . butunclebob.com .
  6. ↑ مارتن 2003 ، الصفحات 95-98 
  7. ↑ ديماركو، توم. (1979). التحليل الهيكلي وتحديد مواصفات النظام . برنتيس هول . ISBN 0-13-854380-1.
  8. ↑ بيج-جونز، ميلير (1988). الدليل العملي لتصميم الأنظمة المهيكلة . سلسلة يوردون برس للحوسبة . ص 82. ISBN  978-8120314825.
  9. ↑ مدونة "Clean Coder" . blog.cleancoder.com .