حذف المعاملات (Remove Parameter)
اذهب إلى التنقل
اذهب إلى البحث
المشكلة
لا يُستخدم معاملٌ ما في متن التابع.
الحل
إزالة المعامل غير المستخدم.
مثال
قبل إعادة التصميم
تعريف المعامل Date في بداية التابع ()getContact وعدم استخدامه.
بعد إعادة التصميم
إزالة المعامل Date من التابع ()getContact لعدم استخدامه:
لم إعادة التصميم؟
يفرض كل معامل موجود في استدعاء التوابع على المبرمج أن يقرأه لمعرفة ما هي المعلومات الموجودة في هذا المعامل. وإذا كان المعامل غير مستخدم على الإطلاق في متن التابع، يصبح الأمر مضيعة للوقت والجهد.
وعلى أية حال، تُشكل المعاملات الإضافية شيفرات إضافية يجب تشغيلها.
في بعض الأحيان نضيف المعاملات استقراءً للمستقبل، على أساس توقع تغييرات على التابع التي قد تكون بحاجة للمعامل. ومع ذلك، تظهر التجربة أنه من الأفضل إضافة معامل فقط عندما يكون هناك حاجة حقيقية إليه. وفي نهاية المطاف، تظل التغيرات المتوقعة في كثير من الأحيان مجرد توقعات.
فوائد تطبيق الحل
- لا يحتوي التابع إلا على المعاملات التي يحتاج إليها حقًا.
متى يترك هذا الحل؟
- يُترك المعامل كما هو، إذا استخدِم التابع بطرق مختلفة في الأصناف الفرعية أو في الأصناف العليا، واستخدِم المُعامل في تلك الطرق المُختلفة.
آلية الحل
- تحقق من إذا كان التابع مُعرَّف في الصنف الأعلى أو صنفٍ فرعي. إذا كان الأمر كذلك، هل أستُخدِم المعامل فيه؟ إذا كان المعامل يستخدم في واحدة من هذه التطبيقات، لا تستخدم هذه التقنية لإعادة التصميم.
- الخطوة التالية مهمة للحفاظ على عمل برنامجك أثناء عملية إعادة التصميم. أنشئ تابعًا جديدًا عن طريق نسخ التابع القديم واحذف المعامل المُراد منه. ثم استبدل الشيفرة البرمجية للتابع القديم باستدعاءٍ للتابع الجديد.
- ابحث عن كافة المراجع إلى التابع القديم واستبدالها بمراجع إلى التابع الجديد.
- احذف التابع القديم. لكن لا تقم بتنفيذ هذه الخطوة إذا كان التابع القديم جزء من واجهة عامة. في هذه الحالة، ضع علامة "مُهمَل" (deprecated) على التابع القديم.
انظر أيضًا
- إضافة المعاملات (Add Parameter).
- إعادة تسمية التوابع (Rename Method).
- تبديل المعاملات باستدعاء التوابع (Replace Parameter with Method Call).
- التخطيط الشمولي المفرط (Speculative Generality).