الفرق بين المراجعتين ل"Refactoring/collapse hierarchy"
اذهب إلى التنقل
اذهب إلى البحث
Khaled-yassin (نقاش | مساهمات) (أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: هدم التسلسل الهرمي (Collapse Hierarchy)}}</noinclude> == المشكلة == في التسلسل الهرمي لصنف يكون...') |
جميل-بيلوني (نقاش | مساهمات) ط (مراجعة وتدقيق.) |
||
| (مراجعة متوسطة واحدة بواسطة مستخدم واحد آخر غير معروضة) | |||
| سطر 1: | سطر 1: | ||
<noinclude>{{DISPLAYTITLE: هدم التسلسل الهرمي (Collapse Hierarchy)}}</noinclude> | <noinclude>{{DISPLAYTITLE: هدم التسلسل الهرمي (Collapse Hierarchy)}}</noinclude> | ||
== المشكلة == | == المشكلة == | ||
| − | في التسلسل الهرمي | + | في التسلسل الهرمي لصنف، يكون صنفٌ فرعي هو عمليًا نفس صنفه الأب. |
== الحل == | == الحل == | ||
| − | دمج الصنف الفرعي والصنف | + | دمج الصنف الفرعي والصنف الأب. |
=== مثال === | === مثال === | ||
==== قبل إعادة التصميم ==== | ==== قبل إعادة التصميم ==== | ||
| − | [[ملف:Collapse Hierarchy - Before.png|بديل=الصنفٌ الفرعي هو عمليًا نفس صنفه الفائق.|بدون|تصغير|الصنفٌ الفرعي هو عمليًا نفس صنفه | + | الصنف الفرعي <code>Salesman</code> هو عمليًّا نفس الصنف <code>Employee</code> له:[[ملف:Collapse Hierarchy - Before.png|بديل=الصنفٌ الفرعي هو عمليًا نفس صنفه الفائق.|بدون|تصغير|الصنفٌ الفرعي هو عمليًا نفس صنفه الأب.]] |
| − | |||
==== بعد إعادة التصميم ==== | ==== بعد إعادة التصميم ==== | ||
| + | دمج الصنف الفرعي <code>Salesman</code> في الصنف الأب:[[ملف:Collapse Hierarchy - After.png|بديل=دمج الصنف الفرعي والصنف الفائق.|بدون|تصغير|دمج الصنف الفرعي والصنف الأب.]] | ||
== لم إعادة التصميم؟ == | == لم إعادة التصميم؟ == | ||
| − | قد يؤدي نمو البرنامج مع مرور الوقت إلى أن يصبح كلٌ من الصنف الفرعي والصنف | + | قد يؤدي نمو البرنامج مع مرور الوقت إلى أن يصبح كلٌ من الصنف الفرعي والصنف الأب تقريبًا نفس الشيء. فتُزال ميزة من الصنف الفرعي، ويُنقل تابع إلى الصنف الأب. والآن لديك صنفين متشابهين. |
== فوائد تطبيق الحل == | == فوائد تطبيق الحل == | ||
| سطر 21: | سطر 21: | ||
* يكون التنقل خلال الشيفرة أسهل عند تعريف التوابع في صنفٍ واحد في وقتٍ مبكر. لا تحتاج إلى تمشيط التسلسل الهرمي بأكمله للعثور على تابعٍ معين. | * يكون التنقل خلال الشيفرة أسهل عند تعريف التوابع في صنفٍ واحد في وقتٍ مبكر. لا تحتاج إلى تمشيط التسلسل الهرمي بأكمله للعثور على تابعٍ معين. | ||
| − | == متى | + | == متى يترك هذا الحل؟ == |
* هل للتسلسل الهرمي للصنف الذي يُعاد تصميمه أكثر من صنف فرعي؟ وإذا كان كذلك، بعد اكتمال إعادة التصميم، يجب أن ترث الأصناف الفرعية المتبقية الصنف الذي ينهدم فيه التسلسل الهرمي. | * هل للتسلسل الهرمي للصنف الذي يُعاد تصميمه أكثر من صنف فرعي؟ وإذا كان كذلك، بعد اكتمال إعادة التصميم، يجب أن ترث الأصناف الفرعية المتبقية الصنف الذي ينهدم فيه التسلسل الهرمي. | ||
| − | * ولكن ضع في اعتبارك أن هذا يمكن أن يؤدي إلى انتهاكات مبدأ ليسكوف للتعويض. على سبيل المثال، إذا كان البرنامج يحاكي شبكات النقل في المدينة وقمت بهدم الصنف | + | * ولكن ضع في اعتبارك أن هذا يمكن أن يؤدي إلى انتهاكات [[wikipedia:Liskov_substitution_principle|مبدأ ليسكوف للتعويض]] (Liskov substitution principle). على سبيل المثال، إذا كان البرنامج يحاكي شبكات النقل في المدينة وقمت بهدم الصنف الأب <code>Transport</code> عن طريق الخطأ في الصنف الفرعي <code>Car</code>، قد يصبح الصنف <code>Plane</code> هو وارث <code>Car</code>. تبًا! |
== آلية الحل == | == آلية الحل == | ||
| − | # حدد أي الصنفين هو الأسهل في الإزالة: الصنف | + | # حدد أي الصنفين هو الأسهل في الإزالة: الصنف الأب أم الصنف الفرعي. |
| − | # إذا قررت التخلص من الصنف | + | # إذا قررت التخلص من الصنف الفرعي، استخدم [[Refactoring/pull up field|سحب الحقل لأعلى]] و<nowiki/>[[Refactoring/pull up method|سحب التابع لأعلى]]. أمَّا إذا اخترت القضاء على الصنف الأب، استخدم [[Refactoring/push down field|دفع الحقل لأسفل]] و<nowiki/>[[Refactoring/push down method|دفع التابع لأسفل]]. |
# استبدل جميع استخدامات الصنف التي تحذفه بالصنف الذي ستنتقل إليه الحقول والتوابع. غالبًا ما تكون شيفرة لإنشاء الأصناف، وكتابة المتغير والمعامل، والتوثيق في تعليقات الشيفرة. | # استبدل جميع استخدامات الصنف التي تحذفه بالصنف الذي ستنتقل إليه الحقول والتوابع. غالبًا ما تكون شيفرة لإنشاء الأصناف، وكتابة المتغير والمعامل، والتوثيق في تعليقات الشيفرة. | ||
# احذف الصنف الفارغ. | # احذف الصنف الفارغ. | ||
== انظر أيضًا == | == انظر أيضًا == | ||
| − | * [[Refactoring/inline class|دمج الصنف | + | * [[Refactoring/inline class|دمج الصنف (Inline Class)]]. |
* [[Refactoring/lazy class|الأصناف الخاملة (Lazy Classes)]]. | * [[Refactoring/lazy class|الأصناف الخاملة (Lazy Classes)]]. | ||
* [[Refactoring/speculative generality|التعميم القائم على الحدس (Speculative Generality)]]. | * [[Refactoring/speculative generality|التعميم القائم على الحدس (Speculative Generality)]]. | ||
| سطر 40: | سطر 40: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Techniques]] | [[تصنيف:Refactoring Techniques]] | ||
| − | [[تصنيف:Dealing with Generalization]] | + | [[تصنيف:Refactoring Dealing with Generalization]] |
المراجعة الحالية بتاريخ 11:29، 26 فبراير 2019
المشكلة
في التسلسل الهرمي لصنف، يكون صنفٌ فرعي هو عمليًا نفس صنفه الأب.
الحل
دمج الصنف الفرعي والصنف الأب.
مثال
قبل إعادة التصميم
الصنف الفرعي Salesman هو عمليًّا نفس الصنف Employee له:
بعد إعادة التصميم
دمج الصنف الفرعي Salesman في الصنف الأب:
لم إعادة التصميم؟
قد يؤدي نمو البرنامج مع مرور الوقت إلى أن يصبح كلٌ من الصنف الفرعي والصنف الأب تقريبًا نفس الشيء. فتُزال ميزة من الصنف الفرعي، ويُنقل تابع إلى الصنف الأب. والآن لديك صنفين متشابهين.
فوائد تطبيق الحل
- تقليل تعقيد البرنامج. تعني الأصناف الأقل أن عدد أشياء أقل قد تشغل الانتباه، وقلق أقل على أجزاء متحركة قابلة للتقسيم عند إجراء التغييرات التي تطرأ على الشيفرة في المستقبل.
- يكون التنقل خلال الشيفرة أسهل عند تعريف التوابع في صنفٍ واحد في وقتٍ مبكر. لا تحتاج إلى تمشيط التسلسل الهرمي بأكمله للعثور على تابعٍ معين.
متى يترك هذا الحل؟
- هل للتسلسل الهرمي للصنف الذي يُعاد تصميمه أكثر من صنف فرعي؟ وإذا كان كذلك، بعد اكتمال إعادة التصميم، يجب أن ترث الأصناف الفرعية المتبقية الصنف الذي ينهدم فيه التسلسل الهرمي.
- ولكن ضع في اعتبارك أن هذا يمكن أن يؤدي إلى انتهاكات مبدأ ليسكوف للتعويض (Liskov substitution principle). على سبيل المثال، إذا كان البرنامج يحاكي شبكات النقل في المدينة وقمت بهدم الصنف الأب
Transportعن طريق الخطأ في الصنف الفرعيCar، قد يصبح الصنفPlaneهو وارثCar. تبًا!
آلية الحل
- حدد أي الصنفين هو الأسهل في الإزالة: الصنف الأب أم الصنف الفرعي.
- إذا قررت التخلص من الصنف الفرعي، استخدم سحب الحقل لأعلى وسحب التابع لأعلى. أمَّا إذا اخترت القضاء على الصنف الأب، استخدم دفع الحقل لأسفل ودفع التابع لأسفل.
- استبدل جميع استخدامات الصنف التي تحذفه بالصنف الذي ستنتقل إليه الحقول والتوابع. غالبًا ما تكون شيفرة لإنشاء الأصناف، وكتابة المتغير والمعامل، والتوثيق في تعليقات الشيفرة.
- احذف الصنف الفارغ.
انظر أيضًا
- دمج الصنف (Inline Class).
- الأصناف الخاملة (Lazy Classes).
- التعميم القائم على الحدس (Speculative Generality).