الفرق بين المراجعتين لصفحة: «Refactoring/middle man»

من موسوعة حسوب
أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:الوسيط (Middle Man)}}</noinclude> == توصيف المشكلة == عندما يكون للصنف (class) مهمةٌ واحدةٌ فقط...'
 
ط مراجعة وتدقيق.
 
سطر 26: سطر 26:
== مصادر ==
== مصادر ==
* [https://refactoring.guru/smells/middle-man صفحة توثيق الوسيط في موقع refactoring.guru.]
* [https://refactoring.guru/smells/middle-man صفحة توثيق الوسيط في موقع refactoring.guru.]
[[تصنيف:Refactoring]]
[[تصنيف:Refactoring Smells]]
[[تصنيف:Refactoring Couplers]]

المراجعة الحالية بتاريخ 15:13، 27 فبراير 2019

توصيف المشكلة

عندما يكون للصنف (class) مهمةٌ واحدةٌ فقط وهي تفويض المهام (delegation) لصنفٍ آخر، فما أهمية وجوده بالأصل؟

أسبابها

  • قد تنتج المشكلة عن التخلُّص المفرط من الاستدعاءات المتسلسلة كعلاجٍ لمشكلة سلاسل الرسائل (message chains).
  • أو قد تنتُج عن النقل التدريجيّ للصنف (class) إلى أصناف أخرى ليبقى الصنف الأصليّ فارغًا إلا من أوامر التفويض (delegation).

وما الحل؟

حذف الوسيط (remove middle man) إن كانت معظم أصناف التابع (method's classes) تفوِّض المهام (delegate) إلى صنفٍ آخر.

إليك المزيد

ستحصل بحلِّ المشكلة على شيفرةٍ أقصر.

تجاهل المشكلة

يجب ألّا يُحذَف الوسيطُ الموجود لتحقيق هدفٍ ما، مثل:

  • تجنُّب الاعتماديّة ما بين الأصناف (interclass dependencies).
  • استخدامه في نماذج التصميم (Design Patterns) مثل: نموذج Proxy أو نموذج Decorator.

انظر أيضًا

مصادر