التوابع الطويلة (Long Methods)

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

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

تنتُج هذه المشكلة عن احتواء شيفرة التابع على الكثير من الأسطر؛ فهو أمرٌ يدعو للتساؤل حقًا إن كان التابع بأكثر من 10 أسطر! لِمَ؟

أسبابها

إنَّ ما يحدث دائمًا أنْ يُضاف للتابع لا أن يُحذَف منه! وذلك لسهولة كتابة الإضافات للشيفرة مقارنةً مع قراءتها، ولن تظهر هذه المشكلة واضحةً إلا بعد تفاقمها ووصولها لحدِ لا يُحتمَل، وكذلك يجد المبرمج أنَّ كتابة تابعٍ جديدٍ أكثرُ مشقّةً من الإضافة لتابعٍ موجودٍ مسبقًا، إذ يفكر: "هما سطران وحسب، ولا داعي لتخصيص تابعٍ منفصلٍ لهما"، وسيقوده هذا التفكير حتمًا لإضافة سطرين هنا وسطرين هناك وآخريَن بمكانٍ آخر إلى أن ينتهي بالحصول على شيفرةٍ فوضويّة (spaghetti code).

وما الحل؟

لتكن القاعدة الأساسيّة: "أضف كلَّ ما هو جديدٌ على التابع بتابعٍ آخر مستقلٍ"، بما فيها الإضافةُ التي لا تتجاوز السطر الواحد (إن كانت بحاجة لبعض التوضيحات [explanations])، وهذا أفضل؛ وخاصّة عندما تكون أسماء التوابع مُعبِّرًة فلا حاجة للنظر المُمعن بمحتواها لمعرفة ما تقوم به. يشمل علاج المشكلة مراعاة النقاط الآتية:

إليك المزيد

من بين جميع الشيفرات كائنية التوجه (object-oriented) تستمر الأصناف (classes) ذوات التوابع الأقصر مدةً أطول والسبب بذلك هو عُسر فهمِ وصيانةِ (maintenance) التوابع الطويلة، والتي هي المرتع الأنسب للنسخ التكرارية (duplicates) غير المرغوبة من الشيفرة، فكن يقظًا!

الأداء (Performance)

هل تؤثِّر زيادةُ عدد التوابع على الأداء كما يدَّعي البعض؟ إنّ تأثيرها لا يستحقُّ النقاش بالأصل لأنّه طفيفٌ ولا داعي للقلق حيال ذلك، أضف لهذا أنّه أصبحت أمامك شيفرةٌ واضحةٌ سهلة الفهم ويسهُل فيها العثور على التوابع الفعّالة، وهذا يساعد (بل وكثيرًا) في إعادة بناء (restructuring) الشيفرة، وهو بحدِّ ذاته ربحٌ عظيمٌ عند الحاجة إليه.

انظر أيضًا

مصادر