الفرق بين المراجعتين لصفحة: «Refactoring/add parameter»
Khaled-yassin (نقاش | مساهمات) طلا ملخص تعديل |
جميل-بيلوني (نقاش | مساهمات) ط مراجعة وتدقيق. |
||
| سطر 9: | سطر 9: | ||
==== قبل إعادة التصميم ==== | ==== قبل إعادة التصميم ==== | ||
[[ملف:Add Parameter - Before.png|بديل=لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات.|بدون|تصغير|لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات.]] | لا يملك التابع <code>()getContact</code> في الصنف <code>Customer</code> لجدولة موعدٍ للتواصل مع الزبون:[[ملف:Add Parameter - Before.png|بديل=لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات.|بدون|تصغير|لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات.]] | ||
==== بعد إعادة التصميم ==== | ==== بعد إعادة التصميم ==== | ||
[[ملف:Add Parameter - After.png|بديل=إنشاء معامل جديد لتمرير البيانات الضرورية.|بدون|تصغير|إنشاء معامل جديد لتمرير البيانات الضرورية.]] | أصبح بالإمكان تمرير تاريخ إلى التابع <code>()getContact</code> لتصبح بيانات جدولة تاريخ مناسب مع الزبون مكتملة:[[ملف:Add Parameter - After.png|بديل=إنشاء معامل جديد لتمرير البيانات الضرورية.|بدون|تصغير|إنشاء معامل جديد لتمرير البيانات الضرورية.]] | ||
== لم إعادة التصميم؟ == | == لم إعادة التصميم؟ == | ||
| سطر 22: | سطر 22: | ||
== مساوئ تطبيق الحل == | == مساوئ تطبيق الحل == | ||
* دائمًا ما تكون إضافة معامل جديد أسهل من إزالته، ولهذا السبب تتضخم قوائم المعاملات في كثير من الأحيان إلى أحجام مهولة. ويُعرف هذا الاختلال باسم [[Refactoring/long parameter list|قائمة المعاملات الطويلة]]. | * دائمًا ما تكون إضافة معامل جديد أسهل من إزالته، ولهذا السبب تتضخم قوائم المعاملات في كثير من الأحيان إلى أحجام مهولة. ويُعرف هذا الاختلال باسم [[Refactoring/long parameter list|قائمة المعاملات الطويلة]]. | ||
* إذا كنت بحاجة إلى إضافة معامل جديد، يعني هذا في بعض الأحيان أن صنفك لا يحتوي على البيانات اللازمة أو أن المعاملات الموجودة لا تحتوي على البيانات الضرورية ذات الصلة. في كلتا الحالتين، | * إذا كنت بحاجة إلى إضافة معامل جديد، يعني هذا في بعض الأحيان أن صنفك لا يحتوي على البيانات اللازمة أو أن المعاملات الموجودة لا تحتوي على البيانات الضرورية ذات الصلة. في كلتا الحالتين، فإنَّ الحل الأفضل هو النظر في نقل البيانات إلى الصنف الرئيسي أو إلى أصناف أخرى يمكن الوصول إلى كائناتها بالفعل من داخل التابع. | ||
== آلية الحل == | == آلية الحل == | ||
# تحقق من إذا كان التابع مُعرَّف في | # تحقق من إذا كان التابع مُعرَّف في الصنف الأعلى أو صنفٍ فرعي. فإذا كان التابع موجودًا فيهما، سوف تحتاج إلى تكرار جميع الخطوات على هذه الأصناف أيضا. | ||
# الخطوة التالية | # الخطوة التالية مهمة للحفاظ على عمل برنامجك أثناء عملية إعادة التصميم. أنشئ تابعًا جديدًا عن طريق نسخ التابع القديم وإضافة المعامل الضروري إليه. ثم استبدل الشيفرة البرمجية للتابع القديم باستدعاءٍ للتابع الجديد. ويمكنك التعويض بأي قيمة في المعامل الجديد (مثل <code>null</code> للكائنات أو صفر للأرقام). | ||
# ابحث عن كافة المراجع إلى التابع القديم واستبدلها بمراجع إلى التابع الجديد. | # ابحث عن كافة المراجع إلى التابع القديم واستبدلها بمراجع إلى التابع الجديد. | ||
# احذف التابع القديم. الحذف غير ممكن إذا كان التابع القديم هو جزء من الواجهة العامة. إذا كان كذلك، ضع علامة "مُهمَل" على التابع القديم. | # احذف التابع القديم. الحذف غير ممكن إذا كان التابع القديم هو جزء من الواجهة العامة. إذا كان كذلك، ضع علامة "مُهمَل" (deprecated) على التابع القديم. | ||
== انظر أيضًا == | == انظر أيضًا == | ||
| سطر 39: | سطر 39: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Techniques]] | [[تصنيف:Refactoring Techniques]] | ||
[[تصنيف:Simplifying Method Calls]] | [[تصنيف:Refactoring Simplifying Method Calls]] | ||
المراجعة الحالية بتاريخ 13:47، 25 فبراير 2019
المشكلة
لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات.
الحل
إنشاء معامل جديد لتمرير البيانات الضرورية.
مثال
قبل إعادة التصميم
لا يملك التابع ()getContact في الصنف Customer لجدولة موعدٍ للتواصل مع الزبون:
بعد إعادة التصميم
أصبح بالإمكان تمرير تاريخ إلى التابع ()getContact لتصبح بيانات جدولة تاريخ مناسب مع الزبون مكتملة:
لم إعادة التصميم؟
تحتاج إلى إجراء بعض تغييرات على أحد التوابع، وتتطلب هذه التغييرات إضافة معلومات أو بيانات لم تكن متاحة من قبل لهذا التابع.
فوائد تطبيق الحل
- يكون الخيار في هذه الحالة إمَّا إضافة معامل جديد وإمَّا إضافة حقل خاص جديد يحتوي على البيانات التي يحتاجها التابع. ويفضل إضافة حقل عند الحاجة إلى بعض البيانات العرضية أو المتغيرة بشكل متكرر والتي لا يوجد جدوى من الاحتفاظ بها في كائن طوال الوقت. في هذه الحالة، سيكون المعامل الجديد أكثر مناسبةً من حقلٍ خاص وستؤتي إعادة التصميم ثمارها. وإلا يُضاف حقلٌ خاص ويُملأ بالبيانات الضرورية قبل استدعاء التابع.
مساوئ تطبيق الحل
- دائمًا ما تكون إضافة معامل جديد أسهل من إزالته، ولهذا السبب تتضخم قوائم المعاملات في كثير من الأحيان إلى أحجام مهولة. ويُعرف هذا الاختلال باسم قائمة المعاملات الطويلة.
- إذا كنت بحاجة إلى إضافة معامل جديد، يعني هذا في بعض الأحيان أن صنفك لا يحتوي على البيانات اللازمة أو أن المعاملات الموجودة لا تحتوي على البيانات الضرورية ذات الصلة. في كلتا الحالتين، فإنَّ الحل الأفضل هو النظر في نقل البيانات إلى الصنف الرئيسي أو إلى أصناف أخرى يمكن الوصول إلى كائناتها بالفعل من داخل التابع.
آلية الحل
- تحقق من إذا كان التابع مُعرَّف في الصنف الأعلى أو صنفٍ فرعي. فإذا كان التابع موجودًا فيهما، سوف تحتاج إلى تكرار جميع الخطوات على هذه الأصناف أيضا.
- الخطوة التالية مهمة للحفاظ على عمل برنامجك أثناء عملية إعادة التصميم. أنشئ تابعًا جديدًا عن طريق نسخ التابع القديم وإضافة المعامل الضروري إليه. ثم استبدل الشيفرة البرمجية للتابع القديم باستدعاءٍ للتابع الجديد. ويمكنك التعويض بأي قيمة في المعامل الجديد (مثل
nullللكائنات أو صفر للأرقام). - ابحث عن كافة المراجع إلى التابع القديم واستبدلها بمراجع إلى التابع الجديد.
- احذف التابع القديم. الحذف غير ممكن إذا كان التابع القديم هو جزء من الواجهة العامة. إذا كان كذلك، ضع علامة "مُهمَل" (deprecated) على التابع القديم.
انظر أيضًا
- حذف المعاملات (Remove Parameter).
- إعادة تسمية التوابع (Rename Method).
- تقديم كائن المُعامل (Introduce Parameter Object).