القائمة الطويلة للمعاملات (Long Parameter List)

من موسوعة حسوب
< Refactoring
مراجعة 07:29، 2 مارس 2019 بواسطة جميل-بيلوني (نقاش | مساهمات) (تعديل التصنيفات)
(فرق) → مراجعة أقدم | المراجعة الحالية (فرق) | مراجعة أحدث ← (فرق)
اذهب إلى التنقل اذهب إلى البحث

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

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

أسبابها

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

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

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

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

وما الحل؟

إليك المزيد

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

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

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

انظر أيضًا

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

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

مصادر