عرض مصدر Refactoring/replace temp with query

<noinclude>{{DISPLAYTITLE:تبديل المتغير المؤقت إلى استدعاء(Replace Temp with Query)}}</noinclude>
== المشكلة ==
تخزين نتيجة تعبيرٍ ما (expression) في متغيِّر محليٍّ (local variable) لاستخدامه لاحقًا في الشيفرة.

== الحل ==
نقل التعبير بأكمله إلى تابعٍ (method) مستقلٍ يعيد نتيجته، وعندها سيكون استدعاء هذا التابع بديلًا عن استخدام المتغيِّر (variable)، ومن الممكن أيضًا دمج هذا التابع مع توابع أخرى عند الحاجة للقيام بذلك.

== مثال ==

=== قبل إعادة التصميم ===
نلاحظ في الشيفرة الآتية وجود متغيِّرٍ مؤقتٍ باسم <code>basePrice</code> لتخزين القيمة الناتجة عن تنفيذ التعبير الرياضيّ بمعامل الجداء (أي المعامل <code>*</code>)، وسيُستخدَم هذا المتغيِّر لاحقًا في الأجزاء الشرطيّة من الشيفرة:<syntaxhighlight lang="java">
double calculateTotal() {
  double basePrice = quantity * itemPrice;
  if (basePrice > 1000) {
    return basePrice * 0.95;
  }
  else {
    return basePrice * 0.98;
  }
}

</syntaxhighlight>

=== بعد إعادة التصميم ===
تتمثَّل إعادة التصميم بالاستغناء عن المتغيِّر المؤقّت <code>basePrice</code> في الشيفرة السابقة واستدعاء التابع <code>basePrice()‎</code> بدلًا عنه، والذي سيعيد نتيجة التعبير الرياضيّ السابق لتصبح الشيفرة كما يلي:<syntaxhighlight lang="java">
double calculateTotal() {
  if (basePrice() > 1000) {
    return basePrice() * 0.95;
  }
  else {
    return basePrice() * 0.98;
  }
}
double basePrice() {
  return quantity * itemPrice;
}

</syntaxhighlight>

== لم إعادة التصميم؟ ==
لتمهيد الطريق لتطبيق تقنيّة الحلّ باستخراج التابع (extract method) على جزءٍ من تابعٍ طويلٍ نسبيًا، وإذا ما وُجِد التعبير ذاته في عدّة توابع أخرى في البرنامج فمن الأفضل إنشاء تابعٍ مشترك (common method).

== فوائد تطبيق الحل ==
* تحسين قابلية قراءة الشيفرة (readability)، إذ إنّ فهمَ هدف التابع المُسمّى <code>getTax()</code>‎ أسهل بكثيرٍ من محاولة فهم السطر التعبيريّ <code>orderPrice() * 0.2</code>.
* الحدُّ من تكرار الشيفرة (duplication) وخاصّة عندما يكون التعبير المُستبدَل مُستخدَمًا في عدّة توابع (methods).

== الأداء (Performance) ==
يتساءل الكثيرون: هل يسبِّب تطبيق هذا الحل مشكلةً بالأداء؟ والإجابة الصريحة: نعم! وذلك لأنّ الشيفرة الناتجة عن الحل ستعتمد على استدعاء تابعٍ جديدٍ بدلًا من اعتمادها على متغيِّرٍ محليٍّ، ولكن مع السرعة الفائقة في المعالجات (CPUs) المستخدَمة اليوم والمترجِمات (compilers) الفعّالة فالمشكلة يسيرة، إذ بالمقارنة مع الشيفرة سهلة القراءة والقدرة على إعادة استخدام التابع مرّاتٍ ومراتٍ في البرنامج (واللتان حصلنا عليهما من تطبيق الحل) فلم يعد هنالك أهمية لتلك المشكلة الطفيفة، أمّا إن كان المتغيِّر مستخدمًا لتخزين نتيجة تعبيرٍ مستهلكٍ للوقت ومكلفٍ حقًا فمن الجيّد العدول عن تطبيق تقنية الحل هذه.

== آلية الحل ==
# التأكُّد من أن قيمة التعبير مُسندةٌ إلى المتغيِّر مرّةً واحدةً (وواحدة فقط) في التابع (method)، فإن لم يكن كذلك، فعليك الانتقال إلى تقنيّة تجزيء المتغيِّر المؤقَّت (split temporary variable) لضمان استخدام المتغيِّر لتخزين نتيجة التعبير فقط.
# تطبيق استخراج التابع (extract method) لوضع التعبير المطلوب في تابعٍ جديدٍ مستقلٍ، والتأكُّد من أنّ هذا التابع الجديد سيعيد قيمة التعبير دون أن يغيّر شيئًا من حالة الكائن (object state)، فإنْ لم يتحقَّق ذلك فيجب عندئذٍ تطبيق تقنيّة عزل الاستدعاء عن المُحدِّد (separate query from modifier).
# تبديل المتغيِّر إلى استدعاءٍ للتابع الجديد المُستحدَث.

== انظر أيضًا ==
* [[Refactoring/inline temp|دمج المتغيِّر المؤقّت]].
* [[Refactoring/split temporary variable|تجزيء المتغيِّر المؤقَّت]].

== مصادر ==
* [https://refactoring.guru/replace-temp-with-query صفحة توثيق تبديل المتغيِّر المؤقَّت إلى استدعاء في موقع refactoring.guru.]
[[تصنيف:Refactoring]]