الاستغناء عن الوسيط (Remove Middle Man)

من موسوعة حسوب
اذهب إلى: تصفح، ابحث

المشكلة

احتواء الصنف (class) على العديد من التوابع (methods) التي تنقل (delegate) سياق البرنامج إلى كائنات (objects) أخرى.

الحل

حذف تلك التوابع وإجبار العميل (client) على الاستدعاء المباشر للتوابع النهائية (التي سيصل إليها بالنهاية وتحتوي المهام الفعليّة).

مثال

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

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

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

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

أصبح تعامل صنف العميل مع الصنفين مباشرةً (وهما Person و Department) واللذان يحتويان على بعض التوابع، ولكنّ الانتقال إلى أحدهما يتمّ عبر العميل مباشرةً دون الحاجة إلى وسيط، أي سيصبح المخطط بالشكل:

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

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

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

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

وقد تحدث نتيجة لتلك الهرميّة بعض المشاكل مثل:

  1. يزيد وجود صنف الخادم من تعقيد البرنامج (complexity) إن لم يكن له أيّ مهمّة فعليّة سوى الانتقال إلى أصنافٍ أخرى.
  2. بمجرَّد إضافة أيّ ميّزة جديدةٍ إلى الوكيل (delegate) فمن الضروري توفير تابعٍ ينقل إليها في صنف الخادم (server)، وسيكون هذا أمرًا منهكًا للغاية عندما تكثر التغييرات في البرنامج.

آلية الحل

  1. إنشاء تابع وصولٍ (getter) للوصول إلى كائن الوكيل (delegate) من كائن الخادم (server).
  2. تبديل استدعاءات التوابع في صنف الخادم باستدعاءات مباشرة للتوابع في صنف الوكيل.

انظر أيضًا

مصادر