الفرق بين المراجعتين ل"Refactoring/remove parameter"
اذهب إلى التنقل
اذهب إلى البحث
Khaled-yassin (نقاش | مساهمات) (أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: حذف المعاملات (Remove Parameter)}}</noinclude> == المشكلة == لا يُستخدم معاملٌ ما في متن التابع...') |
جميل-بيلوني (نقاش | مساهمات) ط (مراجعة وتدقيق.) |
||
| سطر 9: | سطر 9: | ||
==== قبل إعادة التصميم ==== | ==== قبل إعادة التصميم ==== | ||
| − | + | تعريف المعامل <code>Date</code> في بداية التابع <code>()getContact</code> وعدم استخدامه.[[ملف:Remove_Parameter_-_Before.png|بديل=تعريف المعامل Date في بداية التابع ()getContact وعدم استخدامه.|بدون|تصغير|تعريف المعامل Date في بداية التابع ()getContact وعدم استخدامه.]] | |
==== بعد إعادة التصميم ==== | ==== بعد إعادة التصميم ==== | ||
| − | + | إزالة المعامل <code>Date</code> من التابع <code>()getContact</code> لعدم استخدامه:[[ملف:Remove_Parameter_-_After.png|بديل=إزالة المعامل Date من التابع ()getContact.|بدون|تصغير|إزالة المعامل Date من التابع ()getContact.]] | |
== لم إعادة التصميم؟ == | == لم إعادة التصميم؟ == | ||
يفرض كل معامل موجود في استدعاء التوابع على المبرمج أن يقرأه لمعرفة ما هي المعلومات الموجودة في هذا المعامل. وإذا كان المعامل غير مستخدم على الإطلاق في متن التابع، يصبح الأمر مضيعة للوقت والجهد. | يفرض كل معامل موجود في استدعاء التوابع على المبرمج أن يقرأه لمعرفة ما هي المعلومات الموجودة في هذا المعامل. وإذا كان المعامل غير مستخدم على الإطلاق في متن التابع، يصبح الأمر مضيعة للوقت والجهد. | ||
| سطر 17: | سطر 17: | ||
وعلى أية حال، تُشكل المعاملات الإضافية شيفرات إضافية يجب تشغيلها. | وعلى أية حال، تُشكل المعاملات الإضافية شيفرات إضافية يجب تشغيلها. | ||
| − | في بعض الأحيان نضيف المعاملات | + | في بعض الأحيان نضيف المعاملات استقراءً للمستقبل، على أساس توقع تغييرات على التابع التي قد تكون بحاجة للمعامل. ومع ذلك، تظهر التجربة أنه من الأفضل إضافة معامل فقط عندما يكون هناك حاجة حقيقية إليه. وفي نهاية المطاف، تظل التغيرات المتوقعة في كثير من الأحيان مجرد توقعات. |
== فوائد تطبيق الحل == | == فوائد تطبيق الحل == | ||
* لا يحتوي التابع إلا على المعاملات التي يحتاج إليها حقًا. | * لا يحتوي التابع إلا على المعاملات التي يحتاج إليها حقًا. | ||
| − | == متى | + | == متى يترك هذا الحل؟ == |
| − | * يُترك المعامل كما هو، إذا | + | * يُترك المعامل كما هو، إذا استخدِم التابع بطرق مختلفة في الأصناف الفرعية أو في الأصناف العليا، واستخدِم المُعامل في تلك الطرق المُختلفة. |
== آلية الحل == | == آلية الحل == | ||
| − | # تحقق من إذا كان التابع مُعرَّف في | + | # تحقق من إذا كان التابع مُعرَّف في الصنف الأعلى أو صنفٍ فرعي. إذا كان الأمر كذلك، هل أستُخدِم المعامل فيه؟ إذا كان المعامل يستخدم في واحدة من هذه التطبيقات، لا تستخدم هذه التقنية لإعادة التصميم. |
| − | # الخطوة التالية | + | # الخطوة التالية مهمة للحفاظ على عمل برنامجك أثناء عملية إعادة التصميم. أنشئ تابعًا جديدًا عن طريق نسخ التابع القديم واحذف المعامل المُراد منه. ثم استبدل الشيفرة البرمجية للتابع القديم باستدعاءٍ للتابع الجديد. |
# ابحث عن كافة المراجع إلى التابع القديم واستبدالها بمراجع إلى التابع الجديد. | # ابحث عن كافة المراجع إلى التابع القديم واستبدالها بمراجع إلى التابع الجديد. | ||
| − | # احذف التابع القديم. لكن لا تقم بتنفيذ هذه الخطوة إذا كان التابع القديم جزء من واجهة عامة. في هذه الحالة، ضع علامة "مُهمَل" على التابع القديم. | + | # احذف التابع القديم. لكن لا تقم بتنفيذ هذه الخطوة إذا كان التابع القديم جزء من واجهة عامة. في هذه الحالة، ضع علامة "مُهمَل" (deprecated) على التابع القديم. |
== انظر أيضًا == | == انظر أيضًا == | ||
| سطر 41: | سطر 41: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Techniques]] | [[تصنيف:Refactoring Techniques]] | ||
| − | [[تصنيف:Simplifying Method Calls]] | + | [[تصنيف:Refactoring Simplifying Method Calls]] |
المراجعة الحالية بتاريخ 14:05، 25 فبراير 2019
المشكلة
لا يُستخدم معاملٌ ما في متن التابع.
الحل
إزالة المعامل غير المستخدم.
مثال
قبل إعادة التصميم
تعريف المعامل Date في بداية التابع ()getContact وعدم استخدامه.
بعد إعادة التصميم
إزالة المعامل Date من التابع ()getContact لعدم استخدامه:
لم إعادة التصميم؟
يفرض كل معامل موجود في استدعاء التوابع على المبرمج أن يقرأه لمعرفة ما هي المعلومات الموجودة في هذا المعامل. وإذا كان المعامل غير مستخدم على الإطلاق في متن التابع، يصبح الأمر مضيعة للوقت والجهد.
وعلى أية حال، تُشكل المعاملات الإضافية شيفرات إضافية يجب تشغيلها.
في بعض الأحيان نضيف المعاملات استقراءً للمستقبل، على أساس توقع تغييرات على التابع التي قد تكون بحاجة للمعامل. ومع ذلك، تظهر التجربة أنه من الأفضل إضافة معامل فقط عندما يكون هناك حاجة حقيقية إليه. وفي نهاية المطاف، تظل التغيرات المتوقعة في كثير من الأحيان مجرد توقعات.
فوائد تطبيق الحل
- لا يحتوي التابع إلا على المعاملات التي يحتاج إليها حقًا.
متى يترك هذا الحل؟
- يُترك المعامل كما هو، إذا استخدِم التابع بطرق مختلفة في الأصناف الفرعية أو في الأصناف العليا، واستخدِم المُعامل في تلك الطرق المُختلفة.
آلية الحل
- تحقق من إذا كان التابع مُعرَّف في الصنف الأعلى أو صنفٍ فرعي. إذا كان الأمر كذلك، هل أستُخدِم المعامل فيه؟ إذا كان المعامل يستخدم في واحدة من هذه التطبيقات، لا تستخدم هذه التقنية لإعادة التصميم.
- الخطوة التالية مهمة للحفاظ على عمل برنامجك أثناء عملية إعادة التصميم. أنشئ تابعًا جديدًا عن طريق نسخ التابع القديم واحذف المعامل المُراد منه. ثم استبدل الشيفرة البرمجية للتابع القديم باستدعاءٍ للتابع الجديد.
- ابحث عن كافة المراجع إلى التابع القديم واستبدالها بمراجع إلى التابع الجديد.
- احذف التابع القديم. لكن لا تقم بتنفيذ هذه الخطوة إذا كان التابع القديم جزء من واجهة عامة. في هذه الحالة، ضع علامة "مُهمَل" (deprecated) على التابع القديم.
انظر أيضًا
- إضافة المعاملات (Add Parameter).
- إعادة تسمية التوابع (Rename Method).
- تبديل المعاملات باستدعاء التوابع (Replace Parameter with Method Call).
- التخطيط الشمولي المفرط (Speculative Generality).