الفرق بين المراجعتين ل"Refactoring/temporary field"

من موسوعة حسوب
اذهب إلى التنقل اذهب إلى البحث
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:الحقول المؤقتة (Temporary Fields)}}</noinclude> == توصيف المشكلة == تحتوي الحقول المؤقَّتة على...')
 
ط (مراجعة وتدقيق.)
 
سطر 22: سطر 22:
 
[[تصنيف:Refactoring]]
 
[[تصنيف:Refactoring]]
 
[[تصنيف:Refactoring Smells]]
 
[[تصنيف:Refactoring Smells]]
[[تصنيف:Refactoring Fields]]
+
[[تصنيف:Refactoring Object-Orientation Abusers]]

المراجعة الحالية بتاريخ 13:42، 26 فبراير 2019

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

تحتوي الحقول المؤقَّتة على قيمٍ (وتُستخدَم وفقًا لها في الكائنات [objects]) ضمن شروطٍ مُحدَّدة، وتبقى فارغةً عند عدم تحقٌّق تلك الشروط.

أسبابها

تُخصَّصُ الحقول المؤقتة لاستخدامها في الخوارزميات التي تتطلَّب عددًا كبيرًا من المُدخلات (inputs)، فبدلًا من إنشاء الكثير من المعاملات في التابع (method parameters) يلجأ المُبرمِج لإنشاء حقولٍ مؤقَّتة لاحتواء البيانات المطلوبة في الصنف (class)، وبهذا فإنّ استخدام تلك الحقول لا يتعدّى تنفيذَ الخوارزميّة المُحدَّدة (ولا وظيفة أخرى لها خارج ذلك النطاق)، ويجعل وجودُ تلك الحقول من الشيفرة صعبةَ الفهم، إذ في الحين الذي تتوقَّع به وجود قيمٍ لها تجدها فارغة دون أيّ استخدامٍ فعليّ.

وما الحل؟

  • عزل الحقول المؤقتَّة -وكلِّ الشيفرات المرتبطة بها- في صنفٍ (class) مستقلٍ عبر إنشاءٍ صنفٍ جديدٍ ونقلها إليه، وهذا يشابه تمامًا إنشاءَ كائنٍ للتابع (method object) والناتج عن تبديل التابع إلى كائن التابع.
  • إنشاء كائن null‏ (null object) واستخدامه بدلًا من الشيفرة الشرطيّة (conditional code) المُستخدمة للتحقُّق من وجود القيم بالحقول المؤقَّتة.

إليك المزيد

ستحصل على شيفرةٍ أكثر وضوحًا وتنظيمًا.

انظر أيضًا

مصادر