Refactoring/hide delegate

المشكلة

يصل العميل (client) إلى كائنٍ (object) ما وليكن الكائن B من أحد حقول (fields) أو توابع (methods) كائنٍ آخر وليكن A، ومن ثمّ يستدعي تابعًا لهذا الكائن B.

الحل

إنشاء تابعٍ جديدٍ في الصنف A والذي يُفضي إلى استدعاءٍ للكائن B، وبهذا لن يعلم العميل تفاصيل التفويض (delegation) للكائن B ولن يعتمد على ذلك.

مثال

قبل إعادة التصميم

يتعامل صنف العميل (client class) مع صنفين، الأول صنف الأقسام (Department) والثاني صنف الأشخاص (Person) واللذان يحتويان تابعين للحصول على كائنٍ (object) من الصنف الآخر (وهما التابعان getManager و getDepartment)، كما في المخطط الآتي:

مخطط يوضح كيف يتعامل صنف العميل مع الصنفين Person و Department مباشرةً.

بعد إعادة التصميم

أصبح تعامل صنف العميل مع صنفٍ واحدٍ فقط (وهو الصنف Person) والذي بدوره سينتقل (delegate) إلى الصنف الآخر Department دون إرباك العميل بتفاصيل ذلك، كما هو واضح في المخطط:

مخطط يوضح كيف يتعامل صنف العميل مع صنفٍ واحدٍ فقط وهو الصنف Person، والذي بدوره يستدعي كائنًا من صنفٍ آخر باسم Department.

لم إعادة التصميم؟

يجب أولًا الإلمام ببعض المصطلحات:

• الخادم (server): وهو الكائن (object) الذي يكون على تواصلٍ مباشرٍ مع العميل (client).
• المفوض (delegate): وهو الكائن النهائي الذي يحتوي المهام الفعلية التي يطلبها العميل.

وقد تحدث سلسلةٌ من الاستدعاءات (call chain) عندما يطلب العميل كائنًا عبر كائنٍ آخر والذي بدوره سيطلب كائنًا ثالثًا وهكذا، وهذا سيلقي بالعميل بمتاهةٍ من الأصناف والاستدعاءات، أضف لذلك أن أيّ تغييرٍ في بنية العلاقات ما بين تلك الأصناف لا بُدَّ وأن يتبعه تغيير لدى طرف العميل.

فوائد تطبيق الحل

إخفاء التفويض (الانتقال من صنف إلى آخر) عن العميل؛ إذ سيكون من الأسهل إجراء التغييرات على البرنامج إن كانت شيفرة العميل بمعزلٍ عن تفاصيل العلاقات القائمة ما بين الكائنات (objects).

مساوئ تطبيق الحل

سيؤدّي إنشاءُ عددٍ هائلٍ من توابع الانتقال ما بين الأصناف (توابع التفويض [delegation methods]) إلى الحاجة للكثير من الوسطاء (Middle Man)، وهذا بحدّ ذاته مشكلة من مشاكل الشيفرات!

آلية الحل

1. إنشاء تابعٍ (method) في صنف الخادم (server class) لكلِّ تابعٍ يستدعيه العميل في صنف الوكيل (delegate class)، وذلك ليصبح استدعاء صنف الوكيل عبر التوابع الجديدة المُنشَأة في صنف الخادم.
2. تعديل شيفرة العميل (client) لتستدعي توابع صنف الخادم بدلًا من التوابع السابقة.
3. إن كانت تلك التغييرات تغني العميل عن صنف الوكيل، فحينئذٍ من السهل إزالة التوابع الموصلة إلى صنف الوكيل من صنف الخادم (وهي التوابع التي كانت مستخدمةً بالأصل للوصول إلى صنف الوكيل).

انظر أيضًا

• الاستغناء عن الوسيط.
• نقل التابع.

مصادر

• صفحة توثيق إخفاء التفويض في موقع refactoring.guru.