الفرق بين المراجعتين ل"Refactoring/replace delegation with inheritance"
اذهب إلى التنقل
اذهب إلى البحث
Khaled-yassin (نقاش | مساهمات) (أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: استبدال التفويض بالتوريث (Replace Delegation with Inheritance)}}</noinclude> == المشكلة == يحتوي الصنف...') |
جميل-بيلوني (نقاش | مساهمات) ط (مراجعة وتدقيق.) |
||
| سطر 9: | سطر 9: | ||
==== قبل إعادة التصميم ==== | ==== قبل إعادة التصميم ==== | ||
| − | [[ملف:Replace Delegation with Inheritance - Before.png|بديل=يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.|بدون|تصغير|يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.]] | + | التابع الموجود في الصنف <code>Employee</code> مفوَّض إلى التابع <code>()getName</code> في الصنف <code>Person</code>:[[ملف:Replace Delegation with Inheritance - Before.png|بديل=يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.|بدون|تصغير|يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.]] |
==== بعد إعادة التصميم ==== | ==== بعد إعادة التصميم ==== | ||
| − | [[ملف:Replace Delegation with Inheritance - After.png|بديل=أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.|بدون|تصغير|أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.]] | + | جعل الصنف <code>Employee</code> يرث من الصنف <code>Person</code> والتخلص من التفويض:[[ملف:Replace Delegation with Inheritance - After.png|بديل=أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.|بدون|تصغير|أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.]] |
== لم إعادة التصميم؟ == | == لم إعادة التصميم؟ == | ||
| − | يُعد التفويض | + | يُعد التفويض نهجًا أكثر مرونة من التوريث، لأنَّه يسمح بتغيير طريقة تنفيذ التفويض ووضع أصناف أخرى هناك أيضًا. ومع ذلك، لا يصبح التفويض مفيدًا إذا فوضت الإجراءات إلى صنفٍ واحد فقط وجميع توابعه العامة. |
في مثل هذه الحالة، إذا استبدلت التفويض بالتوريث، تُطهِّر الصنف من عدد كبير من توابع التفويض وتعفي نفسك من الحاجة لإنشاءها لكل تابع صنف مفوَّض جديد. | في مثل هذه الحالة، إذا استبدلت التفويض بالتوريث، تُطهِّر الصنف من عدد كبير من توابع التفويض وتعفي نفسك من الحاجة لإنشاءها لكل تابع صنف مفوَّض جديد. | ||
== فوائد تطبيق الحل == | == فوائد تطبيق الحل == | ||
| − | * تقليل طول | + | * تقليل طول الشيفرة، إذ لم نعد بحاجة لجميع توابع التفويض هذه. |
| − | + | == متى يترك هذا الحل؟ == | |
| − | * لا تستخدم هذه التقنية إذا كان الصنف يحتوي على تفويض لجزء فقط من التوابع العامة لصنف المفوَّض. بفعل هذا، ستنتهك مبدأ ليسكوف للتعويض. | + | * لا تستخدم هذه التقنية إذا كان الصنف يحتوي على تفويض لجزء فقط من التوابع العامة لصنف المفوَّض. بفعل هذا، ستنتهك [[wikipedia:Liskov_substitution_principle|مبدأ ليسكوف للتعويض]]. |
* لا يمكن استخدام هذه التقنية إلا إذا كان الصنف لا يزال بدون أصل. | * لا يمكن استخدام هذه التقنية إلا إذا كان الصنف لا يزال بدون أصل. | ||
== آلية الحل == | == آلية الحل == | ||
| − | # اجعل الصنف | + | # اجعل الصنف صنفًا فرعيًّا من الصنف المفوَّض. |
# ضع الكائن الحالي في حقل يحتوي على مرجع إلى الكائن المفوَّض. | # ضع الكائن الحالي في حقل يحتوي على مرجع إلى الكائن المفوَّض. | ||
# احذف التوابع التي لها تفويض بسيط واحدًا تلو الآخر. إذا كانت أسمائهم مختلفة، استخدم [[Refactoring/rename method|إعادة تسمية التابع]] لإعطاء كل التوابع اسمًا واحد. | # احذف التوابع التي لها تفويض بسيط واحدًا تلو الآخر. إذا كانت أسمائهم مختلفة، استخدم [[Refactoring/rename method|إعادة تسمية التابع]] لإعطاء كل التوابع اسمًا واحد. | ||
# استبدل جميع المراجع إلى الحقل المفوَّض بمراجع إلى الكائن الحالي. | # استبدل جميع المراجع إلى الحقل المفوَّض بمراجع إلى الكائن الحالي. | ||
| − | # أزل | + | # أزل الحقل المفوَّض. |
== انظر أيضًا == | == انظر أيضًا == | ||
| سطر 42: | سطر 42: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Techniques]] | [[تصنيف:Refactoring Techniques]] | ||
| − | [[تصنيف:Dealing with Generalization]] | + | [[تصنيف:Refactoring Dealing with Generalization]] |
المراجعة الحالية بتاريخ 11:28، 26 فبراير 2019
المشكلة
يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر.
الحل
جعل الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري.
مثال
قبل إعادة التصميم
التابع الموجود في الصنف Employee مفوَّض إلى التابع ()getName في الصنف Person:
بعد إعادة التصميم
جعل الصنف Employee يرث من الصنف Person والتخلص من التفويض:
لم إعادة التصميم؟
يُعد التفويض نهجًا أكثر مرونة من التوريث، لأنَّه يسمح بتغيير طريقة تنفيذ التفويض ووضع أصناف أخرى هناك أيضًا. ومع ذلك، لا يصبح التفويض مفيدًا إذا فوضت الإجراءات إلى صنفٍ واحد فقط وجميع توابعه العامة.
في مثل هذه الحالة، إذا استبدلت التفويض بالتوريث، تُطهِّر الصنف من عدد كبير من توابع التفويض وتعفي نفسك من الحاجة لإنشاءها لكل تابع صنف مفوَّض جديد.
فوائد تطبيق الحل
- تقليل طول الشيفرة، إذ لم نعد بحاجة لجميع توابع التفويض هذه.
متى يترك هذا الحل؟
- لا تستخدم هذه التقنية إذا كان الصنف يحتوي على تفويض لجزء فقط من التوابع العامة لصنف المفوَّض. بفعل هذا، ستنتهك مبدأ ليسكوف للتعويض.
- لا يمكن استخدام هذه التقنية إلا إذا كان الصنف لا يزال بدون أصل.
آلية الحل
- اجعل الصنف صنفًا فرعيًّا من الصنف المفوَّض.
- ضع الكائن الحالي في حقل يحتوي على مرجع إلى الكائن المفوَّض.
- احذف التوابع التي لها تفويض بسيط واحدًا تلو الآخر. إذا كانت أسمائهم مختلفة، استخدم إعادة تسمية التابع لإعطاء كل التوابع اسمًا واحد.
- استبدل جميع المراجع إلى الحقل المفوَّض بمراجع إلى الكائن الحالي.
- أزل الحقل المفوَّض.
انظر أيضًا
- استبدال التوريث بالتفويض (Replace Inheritance with Delegation).
- الاستغناء عن الوسيط (Remove Middle Man).
- الارتباط الوثيق غير المناسب (Inappropriate Intimacy).