Refactoring/message chains

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

وجود العديد من الاستدعاءات المتسلسلة في الشيفرة، مثل: ‎$a->b()->c()->d()‎.

أسبابها

تحدث المشكلة عند طلب العميل (client request) كائنًا (object) آخر والذي بدوره يطلب كائنًا آخر ثالثًا وهكذا، مما يعني اعتماد العميل على التنقّل (navigation) في بنية الأصناف (class structure)، وبالتالي فإنّ أيّ تعديلٍ في تلك العلاقات سيتطلَّبُ إجراء التعديلات أيضًا على العميل بحدِّ ذاته.

وما الحل؟

• إخفاء التفويض (hide delegate) لحذف الاستدعاءات المُتسلسلة.
• قد يساعد -ببعض الحالات- التفكيرُ بسبب الوصول إلى آخر كائنٍ (object) مستدعى، وعندها يمكن اللجوء إلى استخراج تابعٍ (extract method) يقوم بالمهمة ذاتها، أو الاعتماد على نقل التابع (move method) لجعل المهمّة في بداية سلسلة الاستدعاءات بدلًا من نهايتها.

إليك المزيد

سيخفِّف حلُّ المشكلة من الاعتمادية (dependency) ما بين أصناف (classes) السلسلة الواحدة، كما وسيقلِّلُ أيضًا من حجم الشيفرة المُستخدَمة.

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

قد يُسبِّبُ الإخفاء المفرط للتفويض (aggressive delegate hiding) الحصولَ على شيفرةٍ يصعُب فيها تحديد مكان تنفيذ العمليّات الفعليّة (functionality)، فكن يقظًا لتجنُّب الوقوع بمشكلةٍ أخرى من مشاكل الشيفرات وهي مشكلة الوسيط (middle man).

انظر أيضًا

• إخفاء التفويض (hide delegate)
• استخراج التابع (extract method)
• نقل التابع (move method)
• مشكلة الوسيط (middle man)

مصادر

• صفحة توثيق سلاسل الرسائل في موقع refactoring.guru.