الفرق بين المراجعتين لصفحة: «Refactoring/inappropriate intimacy»
أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:الارتباط الوثيق غير المناسب (Inappropriate Intimacy)}}</noinclude> == توصيف المشكلة == استخدام أح...' |
جميل-بيلوني (نقاش | مساهمات) ط مراجعة وتدقيق. |
||
| سطر 28: | سطر 28: | ||
== مصادر == | == مصادر == | ||
* [https://refactoring.guru/smells/inappropriate-intimacy صفحة توثيق الارتباط الوثيق غير المناسب في موقع refactoring.guru.] | * [https://refactoring.guru/smells/inappropriate-intimacy صفحة توثيق الارتباط الوثيق غير المناسب في موقع refactoring.guru.] | ||
[[تصنيف:Refactoring]] | |||
[[تصنيف:Refactoring Smells]] | |||
[[تصنيف:Refactoring Couplers]] | |||
المراجعة الحالية بتاريخ 15:13، 27 فبراير 2019
توصيف المشكلة
استخدام أحد الأصناف (class) الحقولَ (fields) والتوابعَ (methods) الداخليّة لصنفٍ آخر بكثرة.
أسبابها
تعاملُ الأصناف (classes) مع بعضها بكثرةٍ، وهذا ما يجب أن تكون على درايةٍ به، إذ إنّ التصميم الجيّد يشترط الحدَّ من التواصل فيما بينها ما أمكن، وهذا سيسهِّل صيانتها (maintenace) وإعادة استخدامها (reuse).
وما الحل؟
- نقلُ التوابع (move methods) ونقل الحقول (move fields) من الصنف الحاليّ إلى الصنف الآخر الذي تُستخدَم فيه، وهو الحلُّ الأبسط عندما لا يحتاج الصنف الأول تلك الحقول والتوابع المنقولة.
- استخراج الصنف (extract class) وإخفاء التفويض (hide delegate) للحدِّ من العلاقات بين الصنفين.
- إن كان الصنفان معتمدين على بعضهما (interdependent) اعتمادًا وثيقًا، فالحلُّ بتغيير الارتباط ثنائيّ الاتجاه إلى ارتباطٍ أحاديّ.
- تبديل التفويض (delegation) إلى وراثة (inheritance) إن كان الارتباط ما بين صنفٍ أعلى (superclass) وصنفٍ آخر فرعيّ (subclass).
إليك المزيد
ستحصل بحلِّ المشكلة على:
- تبسيط الدعم (support) وإعادة استخدام الشيفرة.
- شيفرةٍ أكثر تنظيمًا.
انظر أيضًا
- نقلُ التوابع (move methods)
- نقل الحقول (move fields)
- استخراج الصنف (extract class)
- إخفاء التفويض (hide delegate)
- تغيير الارتباط ثنائيّ الاتجاه إلى ارتباطٍ أحاديّ
- تبديل التفويض (delegation) إلى وراثة (inheritance)