الفرق بين المراجعتين ل"Refactoring/preserve whole object"
اذهب إلى التنقل
اذهب إلى البحث
Khaled-yassin (نقاش | مساهمات) (أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: الحفاظ على الكائن كاملًا (Preserve Whole Object)}}</noinclude> == المشكلة == حصولك على عدة قيم من...') |
جميل-بيلوني (نقاش | مساهمات) ط (مراجعة وتدقيق.) |
||
| سطر 1: | سطر 1: | ||
<noinclude>{{DISPLAYTITLE: الحفاظ على الكائن كاملًا (Preserve Whole Object)}}</noinclude> | <noinclude>{{DISPLAYTITLE: الحفاظ على الكائن كاملًا (Preserve Whole Object)}}</noinclude> | ||
== المشكلة == | == المشكلة == | ||
| − | + | جلب عدة قيم من أحد الكائنات، ثم تمريرها كمعاملات إلى أحد التوابع. | |
== الحل == | == الحل == | ||
| سطر 9: | سطر 9: | ||
==== قبل إعادة التصميم ==== | ==== قبل إعادة التصميم ==== | ||
| + | جلب قيمة درجة الحرارة المنخفضة <code>low</code> والمرتفعة <code>high</code> من الكائن <code>daysTempRange</code> ثم تمريرهما إلى التابع <code>()withinTange</code>: | ||
| + | |||
في لغة Java:<syntaxhighlight lang="java"> | في لغة Java:<syntaxhighlight lang="java"> | ||
int low = daysTempRange.getLow(); | int low = daysTempRange.getLow(); | ||
| سطر 30: | سطر 32: | ||
==== بعد إعادة التصميم ==== | ==== بعد إعادة التصميم ==== | ||
| + | تمرير الكائن <code>daysTempRange</code> بالكامل إلى التابع <code>()withinTange</code>: | ||
| + | |||
في لغة Java:<syntaxhighlight lang="java"> | في لغة Java:<syntaxhighlight lang="java"> | ||
boolean withinPlan = plan.withinRange(daysTempRange); | boolean withinPlan = plan.withinRange(daysTempRange); | ||
| سطر 51: | سطر 55: | ||
== فوائد تطبيق الحل == | == فوائد تطبيق الحل == | ||
* رؤية كائنٍ واحدٍ له اسم مفهوم بدلًا من خلط المعاملات. | * رؤية كائنٍ واحدٍ له اسم مفهوم بدلًا من خلط المعاملات. | ||
| − | * إذا احتاج التابع إلى المزيد من البيانات من أحد الكائنات، لن تحتاج إلى | + | * إذا احتاج التابع إلى المزيد من البيانات من أحد الكائنات، لن تحتاج إلى تعديل جميع الأماكن التي يُستخدم فيها التابع - داخل التابع نفسه. |
== مساوئ تطبيق الحل == | == مساوئ تطبيق الحل == | ||
| سطر 57: | سطر 61: | ||
== آلية الحل == | == آلية الحل == | ||
| − | # أنشئ | + | # أنشئ معاملًا داخل التابع للكائن الذي يمكنك الحصول منه على القيم الضرورية. |
| − | # ابدأ في إزالة المعاملات القديمة من التابع واحدًا تلو الآخر، واستبدلها باستدعاءات إلى توابع كائن المعامل ذات الصلة. | + | # ابدأ في إزالة المعاملات القديمة من التابع واحدًا تلو الآخر، واستبدلها باستدعاءات إلى توابع كائن المعامل ذات الصلة. اختبر بعد ذلك البرنامج بعد كل استبدال للمعامل. |
| − | # احذف شيفرة الحصول getter من كائن المعامل الذي سبق استدعاء التابع. | + | # احذف شيفرة الحصول (getter) من كائن المعامل الذي سبق استدعاء التابع. |
== انظر أيضًا == | == انظر أيضًا == | ||
| سطر 73: | سطر 77: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Techniques]] | [[تصنيف:Refactoring Techniques]] | ||
| − | [[تصنيف:Simplifying Method Calls]] | + | [[تصنيف:Refactoring Simplifying Method Calls]] |
المراجعة الحالية بتاريخ 07:23، 26 فبراير 2019
المشكلة
جلب عدة قيم من أحد الكائنات، ثم تمريرها كمعاملات إلى أحد التوابع.
الحل
حاول تمرير الكائن بالكامل بدلًا من ذلك.
مثال
قبل إعادة التصميم
جلب قيمة درجة الحرارة المنخفضة low والمرتفعة high من الكائن daysTempRange ثم تمريرهما إلى التابع ()withinTange:
في لغة Java:
int low = daysTempRange.getLow();
int high = daysTempRange.getHigh();
boolean withinPlan = plan.withinRange(low, high);
في لغة C#:
int low = daysTempRange.GetLow();
int high = daysTempRange.GetHigh();
bool withinPlan = plan.WithinRange(low, high);
في لغة PHP:
$low = $daysTempRange->getLow();
$high = $daysTempRange->getHigh();
$withinPlan = $plan->withinRange($low, $high);
في لغة Python:
low = daysTempRange.getLow()
high = daysTempRange.getHigh()
withinPlan = plan.withinRange(low, high)
بعد إعادة التصميم
تمرير الكائن daysTempRange بالكامل إلى التابع ()withinTange:
في لغة Java:
boolean withinPlan = plan.withinRange(daysTempRange);
في لغة C#:
bool withinPlan = plan.WithinRange(daysTempRange);
في لغة PHP:
$withinPlan = $plan->withinRange($daysTempRange);
في لغة Python:
withinPlan = plan.withinRange(daysTempRange)
لم إعادة التصميم؟
تكمن المشكلة في وجوب استدعاء توابع كائن المعامل المستقبلي كل مرة قبل استدعاء التابع. إذا تغيرت هذه التوابع أو كمية البيانات التي تم الحصول عليها للتابع، سوف نحتاج إلى البحث عن العشرات من هذه الأماكن في البرنامج بعناية وتنفيذ هذه التغييرات في كل منها.
بعد تطبيق تقنية إعادة التصميم هذه، ستُخزَّن شيفرة الحصول على كل البيانات الضرورية في مكان واحد وهو التابع نفسه.
فوائد تطبيق الحل
- رؤية كائنٍ واحدٍ له اسم مفهوم بدلًا من خلط المعاملات.
- إذا احتاج التابع إلى المزيد من البيانات من أحد الكائنات، لن تحتاج إلى تعديل جميع الأماكن التي يُستخدم فيها التابع - داخل التابع نفسه.
مساوئ تطبيق الحل
- يؤدي هذا التحول في بعض الأحيان إلى أن يصبح التابع أقل مرونة: في السابق كان يمكن للتابع الحصول على البيانات من مصادر مختلفة كثيرة، ولكن قصرنا الآن استخدامها على الكائنات ذات واجهة معينة فقط بسبب إعادة التصميم.
آلية الحل
- أنشئ معاملًا داخل التابع للكائن الذي يمكنك الحصول منه على القيم الضرورية.
- ابدأ في إزالة المعاملات القديمة من التابع واحدًا تلو الآخر، واستبدلها باستدعاءات إلى توابع كائن المعامل ذات الصلة. اختبر بعد ذلك البرنامج بعد كل استبدال للمعامل.
- احذف شيفرة الحصول (getter) من كائن المعامل الذي سبق استدعاء التابع.
انظر أيضًا
- تقديم كائن المُعامل (Introduce Parameter Object).
- تبديل المعاملات باستدعاء التوابع (Replace Parameter with Method Call).
- هوس الحقول الأساسية (Primitive Obsession).
- القائمة الطويلة للمعاملات (Long Parameter List).
- التوابع الطويلة (Long Methods).
- البيانات المُجمَّعة (Data Clumps).