الفرق بين المراجعتين ل"Refactoring/data clumps"

من موسوعة حسوب
اذهب إلى التنقل اذهب إلى البحث
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:البيانات المُجمَّعة (Data Clumps)}}</noinclude> == توصيف المشكلة == تكرار مجموعةٍ من المتغيِ...')
 
ط (تعديل التصنيفات)
 
سطر 27: سطر 27:
 
[[تصنيف:Refactoring]]
 
[[تصنيف:Refactoring]]
 
[[تصنيف:Refactoring Smells]]
 
[[تصنيف:Refactoring Smells]]
 +
[[تصنيف:Refactoring Bloaters]]

المراجعة الحالية بتاريخ 07:29، 2 مارس 2019

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

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

أسبابها

تُعزى المشكلة عمومًا للبُنية (structure) البرمجيّة الضعيفة (أو ما يُعرف بمصطلح copypasta programming)، وللتحقُّقِ من وجود هذه المشكلة بالشيفرة احذف إحدى القيم، فإنْ حدث خللٌ نتيجة الحذف فالمشكلة قائمة ويجب علاجها، وإلّا فتلك إشارةٌ حسنةٌ ومن المحبَّذ تجميعُ هذه المتغيِّرات في كائنٍ واحدٍ.

وما الحل؟

  • إنْ كان التكرار بحقول الصنف (class fields)، فالحلُ بإنشاء صنفٍ (class) ونقل الحقول إليه.
  • إنْ كانت مجموعة المتغيِّرات المُكرَّرة مستخدَمةً كمعاملاتٍ للتابع (method parameters) فالأفضل إنشاء كائن المعاملات (parameter object) لفصلها في صنفٍ مستقلٍ.
  • أمّا عند تمرير البيانات إلى توابع (methods) أخرى فإنّ تمريرها ككائنٍ (whole object) أفضل من تمريرها كحقولٍ مُتفرِّقة.
  • أعِد النظر بأمر الشيفرة التي تعتمد على المجموعة المُكرَّرة من الحقول، فرُّبما يكون الحل بنقلها إلى صنفٍ للبيانات (data class).

إليك المزيد

سيزيد علاجك لهذه المشكلة من القدرة على فهم الشيفرة وتنظيمها تنظيمًا أجدى، إذ تصبح العمليات (operations) على البيانات مُجمَّعةً بمكانٍ واحدٍ بدلًا من انتشارها بعدة مواقع في الشيفرة، أضِفْ لهذا أنّك ستحصل على شيفرةٍ أقصر.

تجاهل المشكلة

قد ينشأ عن تمرير كائنٍ (object) كإحدى معاملات التابع (بدلًا من تمرير القيم مُتفرِّقةً) اعتماديّةٌ (dependency) غيرُ مرغوبةٍ ما بين الصنفين (classes)، فإنْ لم يكن هذا أمرًا إيجابيًا فمن الممكن تجاهلُ المشكلة.

انظر أيضًا

مصادر