الفرق بين المراجعتين ل"Refactoring/remove middle man"
اذهب إلى التنقل
اذهب إلى البحث
جميل-بيلوني (نقاش | مساهمات) (إنشاء الصفحة. هذه الصفحة من مساهمات "نور تامر".) |
جميل-بيلوني (نقاش | مساهمات) ط (مراجعة وتدقيق.) |
||
| سطر 10: | سطر 10: | ||
==== قبل إعادة التصميم ==== | ==== قبل إعادة التصميم ==== | ||
يتعامل صنف العميل (client class) مع صنفٍ واحدٍ فقط وهو الصنف <code>Person</code>، والذي بدوره يستدعي كائنًا من صنفٍ آخر باسم <code>Department</code> دون أن يكون العميل على علمٍ بتفاصيل ذلك الاستدعاء، كما هو واضح في مخطط الأصناف الآتي: | يتعامل صنف العميل (client class) مع صنفٍ واحدٍ فقط وهو الصنف <code>Person</code>، والذي بدوره يستدعي كائنًا من صنفٍ آخر باسم <code>Department</code> دون أن يكون العميل على علمٍ بتفاصيل ذلك الاستدعاء، كما هو واضح في مخطط الأصناف الآتي: | ||
| − | [[ملف:Remove-Middle-Man-Before.png|بديل=مخطط يوضح كيف يتعامل صنف العميل مع صنفٍ واحدٍ فقط وهو الصنف Person، والذي بدوره يستدعي كائنًا من صنفٍ آخر باسم Department.|بدون | + | [[ملف:Remove-Middle-Man-Before.png|بديل=مخطط يوضح كيف يتعامل صنف العميل مع صنفٍ واحدٍ فقط وهو الصنف Person، والذي بدوره يستدعي كائنًا من صنفٍ آخر باسم Department.|بدون|مخطط يوضح كيف يتعامل صنف العميل مع صنفٍ واحدٍ فقط وهو الصنف <code>Person</code>، والذي بدوره يستدعي كائنًا من صنفٍ آخر باسم <code>Department</code>.|تصغير|337x337بك]] |
==== بعد إعادة التصميم ==== | ==== بعد إعادة التصميم ==== | ||
أصبح تعامل صنف العميل مع الصنفين مباشرةً (وهما <code>Person</code> و <code>Department</code>) واللذان يحتويان على بعض التوابع، ولكنّ الانتقال إلى أحدهما يتمّ عبر العميل مباشرةً دون الحاجة إلى وسيط، أي سيصبح المخطط بالشكل: | أصبح تعامل صنف العميل مع الصنفين مباشرةً (وهما <code>Person</code> و <code>Department</code>) واللذان يحتويان على بعض التوابع، ولكنّ الانتقال إلى أحدهما يتمّ عبر العميل مباشرةً دون الحاجة إلى وسيط، أي سيصبح المخطط بالشكل: | ||
| − | [[ملف:Remove-Middle-Man-After.png|بديل=مخطط يوضح كيف يتعامل صنف العميل مع الصنفين Person و Department مباشرةً.|بدون | + | [[ملف:Remove-Middle-Man-After.png|بديل=مخطط يوضح كيف يتعامل صنف العميل مع الصنفين Person و Department مباشرةً.|بدون|مخطط يوضح كيف يتعامل صنف العميل مع الصنفين <code>Person</code> و <code>Department</code> مباشرةً.|تصغير|300x300بك]] |
== لم إعادة التصميم؟ == | == لم إعادة التصميم؟ == | ||
| سطر 25: | سطر 25: | ||
== آلية الحل == | == آلية الحل == | ||
| − | # إنشاء تابع وصولٍ | + | # إنشاء تابع وصولٍ (getter) للوصول إلى كائن الوكيل (delegate) من كائن الخادم (server). |
# تبديل استدعاءات التوابع في صنف الخادم باستدعاءات مباشرة للتوابع في صنف الوكيل. | # تبديل استدعاءات التوابع في صنف الخادم باستدعاءات مباشرة للتوابع في صنف الوكيل. | ||
| سطر 35: | سطر 35: | ||
* [https://refactoring.guru/remove-middle-man صفحة توثيق الاستغناء عن الوسيط في موقع refactoring.guru.] | * [https://refactoring.guru/remove-middle-man صفحة توثيق الاستغناء عن الوسيط في موقع refactoring.guru.] | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
| + | [[تصنيف:Refactoring Techniques]] | ||
| + | [[تصنيف:Refactoring Moving Features between Objects]] | ||
المراجعة الحالية بتاريخ 09:10، 2 مارس 2019
المشكلة
احتواء الصنف (class) على العديد من التوابع (methods) التي تنقل (delegate) سياق البرنامج إلى كائنات (objects) أخرى.
الحل
حذف تلك التوابع وإجبار العميل (client) على الاستدعاء المباشر للتوابع النهائية (التي سيصل إليها بالنهاية وتحتوي المهام الفعليّة).
مثال
قبل إعادة التصميم
يتعامل صنف العميل (client class) مع صنفٍ واحدٍ فقط وهو الصنف Person، والذي بدوره يستدعي كائنًا من صنفٍ آخر باسم Department دون أن يكون العميل على علمٍ بتفاصيل ذلك الاستدعاء، كما هو واضح في مخطط الأصناف الآتي:
بعد إعادة التصميم
أصبح تعامل صنف العميل مع الصنفين مباشرةً (وهما Person و Department) واللذان يحتويان على بعض التوابع، ولكنّ الانتقال إلى أحدهما يتمّ عبر العميل مباشرةً دون الحاجة إلى وسيط، أي سيصبح المخطط بالشكل:
لم إعادة التصميم؟
يجب أولًا الإلمام ببعض المصطلحات:
- الخادم (server): وهو الكائن (object) الذي يكون على تواصلٍ مباشرٍ مع العميل (client).
- المفوض (delegate): وهو الكائن النهائي الذي يحتوي المهام الفعلية التي يطلبها العميل.
وقد تحدث نتيجة لتلك الهرميّة بعض المشاكل مثل:
- يزيد وجود صنف الخادم من تعقيد البرنامج (complexity) إن لم يكن له أيّ مهمّة فعليّة سوى الانتقال إلى أصنافٍ أخرى.
- بمجرَّد إضافة أيّ ميّزة جديدةٍ إلى الوكيل (delegate) فمن الضروري توفير تابعٍ ينقل إليها في صنف الخادم (server)، وسيكون هذا أمرًا منهكًا للغاية عندما تكثر التغييرات في البرنامج.
آلية الحل
- إنشاء تابع وصولٍ (getter) للوصول إلى كائن الوكيل (delegate) من كائن الخادم (server).
- تبديل استدعاءات التوابع في صنف الخادم باستدعاءات مباشرة للتوابع في صنف الوكيل.