الروابط الازدواجية (Couplers)
< Refactoring | smells
يتلخّص هذا الجانب بعواقب إنشاء رابطٍ شديدٍ ازدواجيّ (ما بين صنفين [classes])، أو قد تظهر بدائل عنه كالتفويض المفرط (excessive delegation)، وتتمثل هذه المشكلة بالنقاط الآتية:
- التسلط على الكائنات الأخرى (feature envy)
- المشكلة: استخدام بعضُ التوابع بياناتِ الكائنات الأخرى أكثر ممّا تستخدم بياناتِها ذاتَها.
- الحل: إبقاء الأجزاء التي تتغيَّر بآنٍ واحدٍ في المكان ذاته معًا عبر نقلُ التوابع، أو استخراجُ التوابع.
- الارتباط الوثيق غير المناسب (inappropriate intimacy)
- المشكلة: استخدام أحد الأصناف الحقولَ والتوابعَ الداخليّة لصنفٍ آخر بكثرة.
- الحل: نقلُ التوابع ونقل الحقول من الصنف الحاليّ إلى الصنف الآخر الذي تُستخدَم فيه، أو استخراج الصنف وإخفاء التفويض، أو تغيير الارتباط ثنائيّ الاتجاه إلى ارتباطٍ أحاديّ، أو تبديل التفويض إلى وراثة.
- أصناف المكتبة غير الكافية (incomplete library class)
- المشكلة: لا تلبِّي أصناف المكتبة كافّة احتياجات البرنامج مع استمرار تطوُّره، ولا يمكن تعديلها لأنّها مُخصَّصةٌ للقراءة فقط.
- الحل: تعريف التوابع الدخيلة، أو تعريف الإضافات المحليّة.
- سلاسل الرسائل (message chains)
- المشكلة: وجود العديد من الاستدعاءات المتسلسلة في الشيفرة، مثل:
$a->b()->c()->d(). - الحل: إخفاء التفويض لحذف الاستدعاءات المُتسلسلة، أو قد يُلجَأ في بعض الأحيان إلى استخراج تابعٍ يقوم بالمهمة ذاتها، أو الاعتماد على نقل التابع لجعل المهمّة في بداية سلسلة الاستدعاءات بدلًا من نهايتها.
- المشكلة: وجود العديد من الاستدعاءات المتسلسلة في الشيفرة، مثل:
- الوسيط (middle man)
- المشكلة: عندما يكون للصنف مهمةٌ واحدةٌ فقط وهي تفويض المهام لصنفٍ آخر، فما أهمية وجوده بالأصل؟
- الحل: حذف الوسيط إن كانت معظم أصناف التابع تفوِّض المهام إلى صنفٍ آخر.