Refactoring/long parameter list

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

وجود ما يزيد عن ثلاثة أو أربعة معاملات (parameters) مُمرَّرة للتابع (method).

أسبابها

قد تحدث هذه المشكلة عند دمج عدّة خوارزمياتٍ بنفس التابع (method)، إذ تُستخدَم المعاملات (parameters) الكثيرة لتحديد الخوارزمية التي ستُنفَّذ وآليّتها.

أو قد تنتج المشكلة عن محاولة المبرمج أو المطوِّر لجعل الأصناف (classes) أكثر استقلاليةً عن بعضها البعض.

فمثلًا: عند نقل الشيفرة التي تنشِئ الكائنات (objects) -اللازمة لأحد التوابع- من داخل التابع إلى الشيفرة التي تستدعي ذلك التابع سيتطلَّبُ تمرير تلك الكائنات إلى التابع كمعاملاتٍ له، وبهذا فإنّ الصنف الأصليّ لم يعد على اطّلاعٍ بالعلاقات ما بين الكائنات، وهذا يعني اعتماديّةً (dependency) أقلّ (واستقلاليةً أكبر).

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

وما الحل؟

• تحقَّق من القيم المُمرَّرة إلى التابع (method)، فإنْ وُجِد وسيطٌ (argument) تنتُج قيمتُه عن استدعاء تابعٍ لكائنٍ آخر فالحل يكمُن بتبديل ذلك المعامل إلى استدعاءٍ للتابع المطلوب.
• تمرير الكائن ككُلٍّ (whole object) بدلًا من تمرير البيانات المرتبطة بالكائن كمُعاملاتٍ مُتفرِّقة.
• تجميع عناصر البيانات (وإن كانت غير مترابطةٍ) وتمريرها سويةً كمعاملٍ (parameter) عبر إنشاء كائن المعاملات (parameter object).

إليك المزيد

ستحصل بعلاجك المشكلة على شيفرةٍ أقصرَ وأسهل للقراءة، ممّا سيكشف المزيد من الشيفرات المُتكرِّرة (duplicate code) غير المكتشَفة سابقًا.

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

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

انظر أيضًا

تبديل المعامل (parameter) إلى استدعاءٍ للتابع (method call)

كائن المعاملات (parameter object)

مصادر

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