الفرق بين المراجعتين لصفحة: «Refactoring/long method»
أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:التوابع الطويلة (Long Methods)}}</noinclude> == توصيف المشكلة == تنتُج هذه المشكلة عن احتواء...' |
جميل-بيلوني (نقاش | مساهمات) ط تعديل التصنيفات |
||
| سطر 28: | سطر 28: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Smells]] | [[تصنيف:Refactoring Smells]] | ||
[[تصنيف:Refactoring | [[تصنيف:Refactoring Bloaters]] | ||
المراجعة الحالية بتاريخ 07:29، 2 مارس 2019
توصيف المشكلة
تنتُج هذه المشكلة عن احتواء شيفرة التابع على الكثير من الأسطر؛ فهو أمرٌ يدعو للتساؤل حقًا إن كان التابع بأكثر من 10 أسطر! لِمَ؟
أسبابها
إنَّ ما يحدث دائمًا أنْ يُضاف للتابع لا أن يُحذَف منه! وذلك لسهولة كتابة الإضافات للشيفرة مقارنةً مع قراءتها، ولن تظهر هذه المشكلة واضحةً إلا بعد تفاقمها ووصولها لحدِ لا يُحتمَل، وكذلك يجد المبرمج أنَّ كتابة تابعٍ جديدٍ أكثرُ مشقّةً من الإضافة لتابعٍ موجودٍ مسبقًا، إذ يفكر: "هما سطران وحسب، ولا داعي لتخصيص تابعٍ منفصلٍ لهما"، وسيقوده هذا التفكير حتمًا لإضافة سطرين هنا وسطرين هناك وآخريَن بمكانٍ آخر إلى أن ينتهي بالحصول على شيفرةٍ فوضويّة (spaghetti code).
وما الحل؟
لتكن القاعدة الأساسيّة: "أضف كلَّ ما هو جديدٌ على التابع بتابعٍ آخر مستقلٍ"، بما فيها الإضافةُ التي لا تتجاوز السطر الواحد (إن كانت بحاجة لبعض التوضيحات [explanations])، وهذا أفضل؛ وخاصّة عندما تكون أسماء التوابع مُعبِّرًة فلا حاجة للنظر المُمعن بمحتواها لمعرفة ما تقوم به. يشمل علاج المشكلة مراعاة النقاط الآتية:
- الحل الأفضل للحدِّ من طول التابع هو إنشاء توابعَ جديدةٍ لاحتواء الأجزاء التي يمكن عزلها عن التابع الحاليّ والاستعاضة عنها باستدعاءات بسيطةٍ للتوابع المستحدثة.
- إن كانت بعض المتغيِّرات (variables) أو المعاملات (parameters) مرتبطةً بالجزء المنقول للتابع الجديد فلا بُدَّ حينها من تبديل المتغيَّرات المؤقَّتة إلى استداعاءات للدوال (الاعتماد على استدعاء تابعٍ بدلًا من تخزين قيمة التعبير في متغيِّر مؤقَّت [temp]) أو الاعتماد على كائن المعاملات (parameter object) للمعاملات المترابطة بدلًا من المعاملات بحدِّ ذاتها أو التعامل مع الكائن ككُلٍّ (بدلًا من متغيِّراته الجزئيّة).
- إن استمرت المشكلة بعد المحاولات السابقة فالحل يكمن إذن بنقل التابع بأكمله إلى كائنٍ مستقلٍ. راجع تبديل التابع إلى كائن التابع (method object).
- ما يدلُّ على الأجزاء التي من الأفضل نقلها إلى تابعٍ منفصلٍ هو وجود المعاملات الشرطيّة (conditional operators) والحلقات (loops)؛ فعند وجود المعاملات الشرطيّة يكون من المساعد تفكيكُ الشرط (decompose conditionals) أمّا عند وجود الحلقات فالأفضل هو إنشاء تابعٍ جديدٍ لها.
إليك المزيد
من بين جميع الشيفرات كائنية التوجه (object-oriented) تستمر الأصناف (classes) ذوات التوابع الأقصر مدةً أطول والسبب بذلك هو عُسر فهمِ وصيانةِ (maintenance) التوابع الطويلة، والتي هي المرتع الأنسب للنسخ التكرارية (duplicates) غير المرغوبة من الشيفرة، فكن يقظًا!
الأداء (Performance)
هل تؤثِّر زيادةُ عدد التوابع على الأداء كما يدَّعي البعض؟ إنّ تأثيرها لا يستحقُّ النقاش بالأصل لأنّه طفيفٌ ولا داعي للقلق حيال ذلك، أضف لهذا أنّه أصبحت أمامك شيفرةٌ واضحةٌ سهلة الفهم ويسهُل فيها العثور على التوابع الفعّالة، وهذا يساعد (بل وكثيرًا) في إعادة بناء (restructuring) الشيفرة، وهو بحدِّ ذاته ربحٌ عظيمٌ عند الحاجة إليه.