# نمط سلسلة المسؤولية

نمط سلسلة المسؤولية بالانجليزية (Chain-of-responsibility pattern) في التصميم الكائني التوجه هو نمط تصميم سلوكي يتكون من مصدر كائنات الأمر وسلسلة من كائنات المعالجة . يحتوي كل كائن معالجة على منطق يحدد أنواع كائنات الأوامر التي يمكنه معالجتها ؛ يتم تمرير الباقي إلى كائن المعالجة التالي في السلسلة. توجد أيضًا آلية لإضافة كائنات معالجة جديدة إلى نهاية هذه السلسلة.
في تباين نموذج سلسلة المسؤولية القياسي، قد يعمل بعض المتعاملين كمرسلين، قادرين على إرسال الأوامر في مجموعة متنوعة من الاتجاهات، وتشكيل شجرة المسؤولية . في بعض الحالات، يمكن أن يحدث هذا بشكل متكرر، حيث تستدعي معالجة الكائنات كائنات معالجة أعلى بأوامر تحاول حل جزء أصغر من المشكلة ؛ في هذه الحالة، يستمر العودية حتى تتم معالجة الأمر، أو يتم استكشاف الشجرة بأكملها. قد يعمل مترجم XML بهذه الطريقة.
يروج هذا النمط لفكرة الاقتران السائب .
نمط سلسلة المسؤولية متطابق تقريبًا من الناحية الهيكلية مع نمط الديكور ، والفرق هو أنه بالنسبة لمصمم الديكور، تتعامل جميع الفئات مع الطلب، بينما بالنسبة لسلسلة المسؤولية، تتعامل إحدى الفئات في السلسلة بالضبط مع الطلب. هذا تعريف صارم لمفهوم المسؤولية في كتاب GoF. ومع ذلك، فإن العديد من التطبيقات (مثل المسجلات أدناه، أو معالجة حدث واجهة المستخدم، أو عوامل تصفية servlet في Java ، إلخ) تسمح للعديد من العناصر في السلسلة بتحمل المسؤولية.

## الملخص

سلسلة المسؤولية نمط التصميم هو واحد من ثلاثة وعشرين نمطًا معروفًا من أنماط تصميم GoF التي تصف الحلول المشتركة لمشاكل التصميم المتكررة عند تصميم برامج كائنية التوجه مرنة وقابلة لإعادة الاستخدام، أي كائنات يسهل تنفيذها، التغيير والاختبار وإعادة الاستخدام.
ما هي المشاكل التي يمكن أن يحلها نمط تصميم سلسلة المسؤولية؟
* يجب تجنب اقتران مرسل الطلب بالمتلقي الخاص به.
* ينبغي أن يكون من الممكن أن يتعامل أكثر من جهاز استقبال مع الطلب.

### ما الحل الذي يصفه نمط تصميم سلسلة المسؤولية؟

يحدد سلسلة من كائنات المستقبل التي تتحمل المسؤولية، اعتمادًا على ظروف وقت التشغيل، إما للتعامل مع الطلب أو إعادة توجيهه إلى جهاز الاستقبال التالي على السلسلة (إن وجد).
يتيح لنا ذلك إرسال طلب إلى سلسلة من المستلمين دون الحاجة إلى معرفة الشخص الذي يتعامل مع الطلب. يتم تمرير الطلب على طول السلسلة حتى يعالج المستلم الطلب. لم يعد مرسل الطلب مقترنًا بمستقبل معين.
راجع أيضًا فئة UML ومخطط التسلسل أدناه.

## البنية
### فئة UML ومخطط التسلسل

في الرسم التخطيطي لفئة UML أعلاه، Sender إلى فئة مستقبل معينة مباشرة. بدلاً من ذلك، يشير Sender Handler لمعالجة الطلب ( handler.handleRequest ) ، مما يجعل Sender مستقلاً عن المتلقي الذي يتعامل مع الطلب. و Receiver1 ، Receiver2 ، و Receiver3 الطبقات على تنفيذ Handler واجهة إما عن طريق المناولة أو إعادة توجيه الطلب (تبعا للظروف وقت التشغيل).
يوضح الرسم التخطيطي لتسلسل UML تفاعلات وقت التشغيل: في هذا المثال، يستدعي كائن Sender handleRequest على receiver1 (من النوع Handler ). يقوم receiver1 بإعادة توجيه الطلب إلى receiver2 ، والذي بدوره يعيد توجيه الطلب إلى receiver3 ، والذي يتعامل مع (ينفذ) الطلب.

### امثله
#### مثال جافا

يوجد أدناه مثال على هذا النمط في Java. يتم إنشاء المسجل باستخدام سلسلة من المسجلين، كل واحد تم تكوينه بمستويات سجل مختلفة.

#### لغة #C مثال

تستخدم أمثلة لغة #C هذه تطبيق المسجل لتحديد مصادر مختلفة بناءً على مستوى السجل

#### مثال لغة PHP
## تطبيقات
### كاكاو وكاكاو تاتش

تستخدم أطر Cocoa و Cocoa Touch ، المستخدمة في تطبيقات OS X وiOS على التوالي، بنشاط نمط سلسلة المسؤولية للتعامل مع الأحداث. تسمى الكائنات التي تشارك في السلسلة كائنات المستجيب ، وهي NSResponder من فئة NSResponder (OS X) / UIResponder (iOS). كافة الكائنات عرض ( NSView / UIView )، وكائنات رأي تحكم ( NSViewController / UIViewController )، والأشياء نافذة ( NSWindow / UIWindow )، والكائن التطبيق ( NSApplication / UIApplication ) هي كائنات الرد.
عادةً، عندما يتلقى أحد العروض حدثًا لا يمكنه التعامل معه، فإنه يرسله إلى العرض الإشرافي الخاص به حتى يصل إلى وحدة التحكم في العرض أو كائن النافذة. إذا لم تتمكن النافذة من معالجة الحدث، فسيتم إرسال الحدث إلى كائن التطبيق، وهو الكائن الأخير في السلسلة. على سبيل المثال:
* في OS X ، يمكن تحريك نافذة مزخرفة بالماوس من أي مكان (وليس فقط شريط العنوان) ، ما لم يكن هناك عرض في هذا الموقع يتعامل مع أحداث السحب، مثل عناصر التحكم في شريط التمرير. إذا لم يكن هناك مثل هذا العرض (أو العرض المشرف) ، فسيتم إرسال أحداث السحب لأعلى في السلسلة إلى النافذة التي تتعامل مع حدث السحب.
* في نظام التشغيل iOS ، من المعتاد التعامل مع أحداث العرض في وحدة التحكم في العرض التي تدير التسلسل الهرمي للعرض، بدلاً من تصنيف العرض نفسه. نظرًا لأن وحدة التحكم في العرض تقع في سلسلة المستجيب بعد جميع العروض الفرعية المُدارة، فيمكنها اعتراض أي أحداث عرض والتعامل معها.