الفرق بين المراجعتين ل"Refactoring/lazy class"
اذهب إلى التنقل
اذهب إلى البحث
(أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:الأصناف الخاملة (Lazy Classes)}}</noinclude> == توصيف المشكلة == وجود بعض الأصناف (classes) قليلة...') |
جميل-بيلوني (نقاش | مساهمات) ط (مراجعة وتدقيق.) |
||
| سطر 25: | سطر 25: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Smells]] | [[تصنيف:Refactoring Smells]] | ||
| − | [[تصنيف:Refactoring | + | [[تصنيف:Refactoring Dispensables]] |
| − | |||
المراجعة الحالية بتاريخ 14:58، 26 فبراير 2019
توصيف المشكلة
وجود بعض الأصناف (classes) قليلة الاستخدام ولا أهمية لها في البرنامج، ويجدر التخلُّص منها إذ إنّ فهم وصيانة الأصناف يكلِّفان الوقت والجهد.
أسبابها
- يكون تصميم الصنف بدايةً لأداء مهامٍ (functionality) معيّنة، ولكنّه قد يصبح صغيرًا لا أهميّة له من بعد الكثير من عمليات إعادة التصميم (refactoring).
- قد تُخصَّص بعض الأصناف لدعم التطوير المستقبلي للبرنامج (كالتخطيط المُسبق لميّزاتٍ ستُضاف لاحقًا)، وتصبح تلك الأصناف خاملةً عندما لا يحدث أيُّ تطويرٍ فيما بعد.
وما الحل؟
- تضمين الأصناف (inline classes) للعناصر (components) شبه الخاملة بهدف نقلها لصنفٍ آخر.
- هدم الهيكليّة الهرميّة (collapse hierarchy) للأصناف الفرعيّة ذات المهام الضئيلة.
إليك المزيد
ستحصل بحلِّ المشكلة على شيفرةٍ أقصر ذات صيانةٍ أسهل.
تجاهل المشكلة
قد يُفيد تجاهل المشكلة عندما تكون الأصناف بهدف التطوير المستقبليّ، ولكن يجب عندئذٍ الحفاظ على الموازنة ما بين الوضوح والبساطة في الشيفرة.