تبديل المتغير المؤقت إلى استدعاء(Extract Methods)
المشكلة
تخزين نتيجة تعبيرٍ ما (expression) في متغيِّر محليٍّ (local variable) لاستخدامه لاحقًا في الشيفرة.
الحل
نقل التعبير بأكمله إلى تابعٍ (method) مستقلٍ يعيد نتيجته، وعندها سيكون استدعاء هذا التابع بديلًا عن استخدام المتغيِّر (variable)، ومن الممكن أيضًا دمج هذا التابع مع توابع أخرى عند الحاجة للقيام بذلك.
مثال
قبل إعادة التصميم
نلاحظ في الشيفرة الآتية وجود متغيِّرٍ مؤقتٍ باسم basePrice لتخزين القيمة الناتجة عن تنفيذ التعبير الرياضيّ بمعامل الجداء (أي المعامل *)، وسيُستخدَم هذا المتغيِّر لاحقًا في الأجزاء الشرطيّة من الشيفرة:
double calculateTotal() {
double basePrice = quantity * itemPrice;
if (basePrice > 1000) {
return basePrice * 0.95;
}
else {
return basePrice * 0.98;
}
}
بعد إعادة التصميم
تتمثَّل إعادة التصميم بالاستغناء عن المتغيِّر المؤقّت basePrice في الشيفرة السابقة واستدعاء التابع basePrice() بدلًا عنه، والذي سيعيد نتيجة التعبير الرياضيّ السابق لتصبح الشيفرة كما يلي:
double calculateTotal() {
if (basePrice() > 1000) {
return basePrice() * 0.95;
}
else {
return basePrice() * 0.98;
}
}
double basePrice() {
return quantity * itemPrice;
}
لم إعادة التصميم؟
لتمهيد الطريق لتطبيق تقنيّة الحلّ باستخراج التابع (extract method) على جزءٍ من تابعٍ طويلٍ نسبيًا، وإذا ما وُجِد التعبير ذاته في عدّة توابع أخرى في البرنامج فمن الأفضل إنشاء تابعٍ مشترك (common method).
فوائد تطبيق الحل
- تحسين قابلية قراءة الشيفرة (readability)، إذ إنّ فهمَ هدف التابع المُسمّى
getTax() أسهل بكثيرٍ من محاولة فهم السطر التعبيريّorderPrice() * 0.2. - الحدُّ من تكرار الشيفرة (duplication) وخاصّة عندما يكون التعبير المُستبدَل مُستخدَمًا في عدّة توابع (methods).
الأداء (Performance)
يتساءل الكثيرون: هل يسبِّب تطبيق هذا الحل مشكلةً بالأداء؟ والإجابة الصريحة: نعم! وذلك لأنّ الشيفرة الناتجة عن الحل ستعتمد على استدعاء تابعٍ جديدٍ بدلًا من اعتمادها على متغيِّرٍ محليٍّ، ولكن مع السرعة الفائقة في المعالجات (CPUs) المستخدَمة اليوم والمترجِمات (compilers) الفعّالة فالمشكلة يسيرة، إذ بالمقارنة مع الشيفرة سهلة القراءة والقدرة على إعادة استخدام التابع مرّاتٍ ومراتٍ في البرنامج (واللتان حصلنا عليهما من تطبيق الحل) فلم يعد هنالك أهمية لتلك المشكلة الطفيفة، أمّا إن كان المتغيِّر مستخدمًا لتخزين نتيجة تعبيرٍ مستهلكٍ للوقت ومكلفٍ حقًا فمن الجيّد العدول عن تطبيق تقنية الحل هذه.
آلية الحل
- التأكُّد من أن قيمة التعبير مُسندةٌ إلى المتغيِّر مرّةً واحدةً (وواحدة فقط) في التابع (method)، فإن لم يكن كذلك، فعليك الانتقال إلى تقنيّة تجزيء المتغيِّر المؤقَّت (split temporary variable) لضمان استخدام المتغيِّر لتخزين نتيجة التعبير فقط.
- تطبيق استخراج التابع (extract method) لوضع التعبير المطلوب في تابعٍ جديدٍ مستقلٍ، والتأكُّد من أنّ هذا التابع الجديد سيعيد قيمة التعبير دون أن يغيّر شيئًا من حالة الكائن (object state)، فإنْ لم يتحقَّق ذلك فيجب عندئذٍ تطبيق تقنيّة عزل الاستدعاء عن المُحدِّد (separate query from modifier).
- تبديل المتغيِّر إلى استدعاءٍ للتابع الجديد المُستحدَث.