الفرق بين المراجعتين ل"Refactoring/introduce parameter object"
اذهب إلى التنقل
اذهب إلى البحث
Khaled-yassin (نقاش | مساهمات) |
جميل-بيلوني (نقاش | مساهمات) ط (مراجعة وتدقيق.) |
||
| سطر 9: | سطر 9: | ||
==== قبل إعادة التصميم ==== | ==== قبل إعادة التصميم ==== | ||
| − | [[ملف:Introduce Parameter Object - Before.png|بديل=تحتوي التوابع على نفس المجموعة المتكررة من المعاملات.|بدون|تصغير|تحتوي التوابع على نفس المجموعة المتكررة من المعاملات.]] | + | تمرير نفس مجموعة المعاملات إلى توابع الصنف <code>Customer</code>:[[ملف:Introduce Parameter Object - Before.png|بديل=تحتوي التوابع على نفس المجموعة المتكررة من المعاملات.|بدون|تصغير|تحتوي التوابع على نفس المجموعة المتكررة من المعاملات.]] |
==== بعد إعادة التصميم ==== | ==== بعد إعادة التصميم ==== | ||
| − | [[ملف:Introduce Parameter Object - After.png|بديل=استبدال هذه المعاملات بكائنٍ واحد.|بدون|تصغير|استبدال هذه المعاملات بكائنٍ واحد.]] | + | تبديل كائن واحد بتلك المعاملات وتمريره إلى توابع الصنف <code>Customer</code> التي تشترك بنفس مجموعة المعاملات:[[ملف:Introduce Parameter Object - After.png|بديل=استبدال هذه المعاملات بكائنٍ واحد.|بدون|تصغير|استبدال هذه المعاملات بكائنٍ واحد.]] |
== لم إعادة التصميم؟ == | == لم إعادة التصميم؟ == | ||
| − | غالبًا ما تُصادَف مجموعات متطابقة من المعاملات داخل العديد من التوابع. الأمر الذي يؤدي إلى تكرار الشيفرة البرمجية | + | غالبًا ما تُصادَف مجموعات متطابقة من المعاملات داخل العديد من التوابع. الأمر الذي يؤدي إلى تكرار الشيفرة البرمجية للمعاملات نفسها والعمليات ذات الصلة بها. عند توحيد المعايير في صنف واحد، يمكن أيضًا أن تنقل إليه توابع التعامل مع هذه البيانات لإزالة التوابع الأخرى من هذه الشيفرة. |
== فوائد تطبيق الحل == | == فوائد تطبيق الحل == | ||
* تصبح الشيفرة أكثر قابلية للقراءة؛ ويصبح كائنٌ واحدٌ له اسم مفهوم بدلًا من خلط المعاملات. | * تصبح الشيفرة أكثر قابلية للقراءة؛ ويصبح كائنٌ واحدٌ له اسم مفهوم بدلًا من خلط المعاملات. | ||
| − | * تُنشئ المجموعات المتطابقة من المعاملات والمتناثرة هنا وهناك نوعًا خاصًا بها من ازدواجية الشيفرة: في حين لا تُستدعى الشيفرات المتطابقة، | + | * تُنشئ المجموعات المتطابقة من المعاملات والمتناثرة هنا وهناك نوعًا خاصًا بها من ازدواجية الشيفرة: في حين لا تُستدعى الشيفرات المتطابقة، توجد مجموعات من المعاملات والوسائط باستمرار. |
== مساوئ تطبيق الحل == | == مساوئ تطبيق الحل == | ||
| سطر 25: | سطر 25: | ||
== آلية الحل == | == آلية الحل == | ||
| − | # أنشئ | + | # أنشئ صنفًا جديدًا يمثل مجموعة المعاملات الخاصة بك. اجعل الصنف غير قابل للتغيير. |
| − | # استخدم [[Refactoring/add parameter|إضافة معامل]] في التابع الذي تريد إعادة تصميمه، حيث سيُمرر كائن المعامل. في كافة استدعاءات التابع، | + | # استخدم [[Refactoring/add parameter|إضافة معامل]] في التابع الذي تريد إعادة تصميمه، حيث سيُمرر كائن المعامل. في كافة استدعاءات التابع، مرِّر الكائن الذي أُنشئ من معاملات التابع القديم إلى هذا المعامل. |
# ابدأ الآن في إزالة المعاملات القديمة من التابع واحدًا تلو الآخر، واستبدالها في الشيفرة بحقول من كائن المعامل. ثم جرب البرنامج بعد استبدال كل معامل. | # ابدأ الآن في إزالة المعاملات القديمة من التابع واحدًا تلو الآخر، واستبدالها في الشيفرة بحقول من كائن المعامل. ثم جرب البرنامج بعد استبدال كل معامل. | ||
# عند الانتهاء، راجع ما إذا كان هناك أي استفادة من نقل جزء من التابع (أو في بعض الأحيان التابع بأكمله) إلى صنف كائن معامل. إذا كان الأمر كذلك، استخدم [[Refactoring/move method|نقل التوابع]] أو <nowiki/>[[Refactoring/extract method|استخراج التوابع]]. | # عند الانتهاء، راجع ما إذا كان هناك أي استفادة من نقل جزء من التابع (أو في بعض الأحيان التابع بأكمله) إلى صنف كائن معامل. إذا كان الأمر كذلك، استخدم [[Refactoring/move method|نقل التوابع]] أو <nowiki/>[[Refactoring/extract method|استخراج التوابع]]. | ||
| سطر 41: | سطر 41: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Techniques]] | [[تصنيف:Refactoring Techniques]] | ||
| − | [[تصنيف:Simplifying Method Calls]] | + | [[تصنيف:Refactoring Simplifying Method Calls]] |
مراجعة 07:49، 26 فبراير 2019
المشكلة
تحتوي التوابع على نفس المجموعة المتكررة من المعاملات.
الحل
استبدال هذه المعاملات بكائنٍ واحد.
مثال
قبل إعادة التصميم
تمرير نفس مجموعة المعاملات إلى توابع الصنف Customer:
بعد إعادة التصميم
تبديل كائن واحد بتلك المعاملات وتمريره إلى توابع الصنف Customer التي تشترك بنفس مجموعة المعاملات:
لم إعادة التصميم؟
غالبًا ما تُصادَف مجموعات متطابقة من المعاملات داخل العديد من التوابع. الأمر الذي يؤدي إلى تكرار الشيفرة البرمجية للمعاملات نفسها والعمليات ذات الصلة بها. عند توحيد المعايير في صنف واحد، يمكن أيضًا أن تنقل إليه توابع التعامل مع هذه البيانات لإزالة التوابع الأخرى من هذه الشيفرة.
فوائد تطبيق الحل
- تصبح الشيفرة أكثر قابلية للقراءة؛ ويصبح كائنٌ واحدٌ له اسم مفهوم بدلًا من خلط المعاملات.
- تُنشئ المجموعات المتطابقة من المعاملات والمتناثرة هنا وهناك نوعًا خاصًا بها من ازدواجية الشيفرة: في حين لا تُستدعى الشيفرات المتطابقة، توجد مجموعات من المعاملات والوسائط باستمرار.
مساوئ تطبيق الحل
- إذا نقلت البيانات فقط إلى صنف جديد ولم تخطط لنقل أي سلوكيات أو عمليات ذات الصلة إليه، يبدأ هذا في إحداث اختلال في أصناف البيانات.
آلية الحل
- أنشئ صنفًا جديدًا يمثل مجموعة المعاملات الخاصة بك. اجعل الصنف غير قابل للتغيير.
- استخدم إضافة معامل في التابع الذي تريد إعادة تصميمه، حيث سيُمرر كائن المعامل. في كافة استدعاءات التابع، مرِّر الكائن الذي أُنشئ من معاملات التابع القديم إلى هذا المعامل.
- ابدأ الآن في إزالة المعاملات القديمة من التابع واحدًا تلو الآخر، واستبدالها في الشيفرة بحقول من كائن المعامل. ثم جرب البرنامج بعد استبدال كل معامل.
- عند الانتهاء، راجع ما إذا كان هناك أي استفادة من نقل جزء من التابع (أو في بعض الأحيان التابع بأكمله) إلى صنف كائن معامل. إذا كان الأمر كذلك، استخدم نقل التوابع أو استخراج التوابع.
انظر أيضًا
- الحفاظ علي الكائن كاملًا (Preserve Whole Object).
- القائمة الطويلة للمعاملات (Long Parameter List).
- البيانات المُجمَّعة (Data Clumps).
- هوس الحقول الأساسية (Primitive Obsession).
- التوابع الطويلة (Long Methods).