الفرق بين المراجعتين ل"Refactoring/feature envy"

من موسوعة حسوب
اذهب إلى التنقل اذهب إلى البحث
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:التسلط على الكائنات الأخرى (Feature Envy)}}</noinclude> == توصيف المشكلة == استخدام بعضُ التو...')
 
ط (مراجعة وتدقيق.)
 
سطر 29: سطر 29:
 
== مصادر ==
 
== مصادر ==
 
* [https://refactoring.guru/smells/feature-envy صفحة توثيق التسلط على الكائنات الأخرى في موقع refactoring.guru.]
 
* [https://refactoring.guru/smells/feature-envy صفحة توثيق التسلط على الكائنات الأخرى في موقع refactoring.guru.]
 +
[[تصنيف:Refactoring]]
 +
[[تصنيف:Refactoring Smells]]
 +
[[تصنيف:Refactoring Couplers]]

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

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

استخدام بعضُ التوابع (methods) بياناتِ الكائنات (objects) الأخرى أكثر ممّا تستخدم بياناتِها ذاتَها.

أسبابها

تحدث هذه المشكلة عقب نقل الحقول (fields) إلى أصناف البيانات (data class)، إذ من الأفضل نقلُ التوابع المستخدِمة لتلك الحقول لذلك الصنف أيضًا.

وما الحل؟

لنضع بالحسبان القاعدة الآتية:

يجب أن تبقى الأجزاء التي تتغيَّر بآنٍ واحدٍ في المكان ذاته معًا

ولتحقيق ذلك:

  • نقلُ التوابع (move methods) إلى المكان الأنسب في الشيفرة.
  • عندما يستخدِم جزءٌ فقط من التابع بياناتِ كائنٍ (object) آخر، فالأفضل استخراجُ تابعٍ (extract method) جديدٍ لنقل ذلك الجزء إليه.
  • إن كان التابع يستخدم عمليّاتٍ (functions) من العديد من الأصناف الأخرى، فيجب أولًا تحديد أيّ صنفٍ يحتوي على أكثر البيانات المستخدَمة ونقل هذا التابع إليه بالإضافة إلى البيانات الأخرى، أو قد يكون الحل باستخراج التابع (extract method) لفصل التابع إلى عدِّة أجزاء تُوزَّع بعدِّة أماكن في أصناف متفرِّقة.

إليك المزيد

ستحصل بحلِّ المشكلة على:

  • التقليل من تكرار (duplication) الشيفرات؛ بسبب وجود الشيفرة المُستخدِمة للبيانات في مكانٍ مركزيّ.
  • شيفرةٍ أكثر تنظيمًا؛ إذ تصبح الشيفرات مجاورةً للبيانات التي تستخدمها.

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

قد يُوضَع السلوك (behaviour) -عمدًا- بعيدًا عن الصنف الذي يحتوي البيانات التي يتعامل معها، وذلك بهدف القدرة على تغييره ديناميكيًا (راجع نماذج التصميم Strategy و Visitor وما يماثلهما).

انظر أيضًا

مصادر