Refactoring/large class

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

احتواء الصنف (class) العديدَ من الحقول (fields) والتوابع (methods) وشيفرةً بأسطرَ كثيرةٍ.

أسبابها

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

وما الحل؟

الحل بسيطٌ جدًا؛ وهو تقسيم الصنف، وذلك بإحدى الوسائل الآتية:

• إنشاء صنفٍ جديدٍ (Extract Class) إن كان من الممكن فصلُ بعض مهامّ الصنف الحاليّ ونقلها للصنف الجديد.
• إنشاء صنفٍ فرعيٍّ (Extract Subclass) لدى وجود جزءٍ يمكن تعريف استخدامه (implementation) بأكثر من طريقة، أو إن كان نادر الاستخدام بالأصل.
• إنشاء واجهةٍ (Extract Interface) عند الحاجة لوجود قائمةٍ بالعمليّات (operations) والإجراءات (functions) التي سيستفيد منها العميل (client).
• أمّا إن كان الصنف مسؤولًا عن واجهةٍ رسوميّةٍ (graphical interface) فالأفضلُ حينها نقلُ بعض بياناته ومهامّه (functions) إلى كائنٍ مجاليّ (domain object)، وسيصبح من الضروري عندئذٍ تخزينُ بعض البيانات في مكانين مع إبقائها متماشيةً (consistent) مع بعضها، وللمزيد عن كيفيّة القيام بذلك راجع البيانات المُكرَّرة المراقَبَة (Duplicate Observed Data).

إليك المزيد

توفِّر إعادة تصميم (refactoring) الأصناف الواسعة على المُطوِّر الحاجة لتذكُّر العدد الكبير لخصائص الصنف (class attributes)، وتمنع كذلك تكرار (duplication) الشيفرة والمهامّ البرمجيّة (functions).

انظر أيضًا

• استخراج الأصناف (Extract Class)
• استخراج الأصناف الفرعيٍّة (Extract Subclass)
• استخراج الواجهات (Extract Interface)
• البيانات المُكرَّرة المراقَبَة (Duplicate Observed Data)

مصادر

• صفحة توثيق الأصناف الواسعة في موقع refactoring.guru.