الفرق بين المراجعتين لصفحة: «Refactoring/hide method»
Khaled-yassin (نقاش | مساهمات) أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE: إخفاء التابع (Hide Method)}}</noinclude> == المشكلة == لا يُستخدم التابع من قِبل الأصناف الأ...' |
جميل-بيلوني (نقاش | مساهمات) ط مراجعة وتدقيق. |
||
| سطر 9: | سطر 9: | ||
==== قبل إعادة التصميم ==== | ==== قبل إعادة التصميم ==== | ||
[[ملف:Hide Method - Before.png|بديل=لا يُستخدم التابع من قِبل الأصناف الأخرى أو يستخدم فقط داخل التسلسل الهرمي للصنف الخاص به.|بدون|تصغير|لا يُستخدم التابع من قِبل الأصناف الأخرى أو يستخدم فقط داخل التسلسل الهرمي للصنف الخاص به.]] | لا يستخدم التابع <code>()aMethod</code> من قبل أصناف أخرى غير الصنف <code>Employee</code> المعرف فيه:[[ملف:Hide Method - Before.png|بديل=لا يُستخدم التابع من قِبل الأصناف الأخرى أو يستخدم فقط داخل التسلسل الهرمي للصنف الخاص به.|بدون|تصغير|لا يُستخدم التابع من قِبل الأصناف الأخرى أو يستخدم فقط داخل التسلسل الهرمي للصنف الخاص به.]] | ||
==== بعد إعادة التصميم ==== | ==== بعد إعادة التصميم ==== | ||
[[ملف:Hide Method - After.png|بديل=جعل التابع خاصًا أو محميًا.|بدون|تصغير|جعل التابع خاصًا أو محميًا.]] | جعل التابع <code>()aMethod</code> خاصًّا ومحميًّا بإخفائه عن الأصناف الأخرى:[[ملف:Hide Method - After.png|بديل=جعل التابع خاصًا أو محميًا.|بدون|تصغير|جعل التابع خاصًا أو محميًا.]] | ||
== لم إعادة التصميم؟ == | == لم إعادة التصميم؟ == | ||
في كثير من الأحيان، ترجع الحاجة إلى إخفاء توابع الحصول على القيم وضبطها إلى تطوير واجهة أكثر ثراءً توفر سلوكًا إضافيًا، خاصة إذا كنت بدأت بصنف يضيف أكثر قليلًا من مجرد تغليف البيانات. | في كثير من الأحيان، ترجع الحاجة إلى إخفاء توابع الحصول على القيم وضبطها إلى تطوير واجهة أكثر ثراءً توفر سلوكًا إضافيًا، خاصة إذا كنت بدأت بصنف يضيف أكثر قليلًا من مجرد تغليف البيانات. | ||
مع وجود سلوك جديد | مع وجود سلوك جديد مبنيٌ في الصنف، قد تجد أنَّ كلًا من توابع الجلب (getter) والضبط (setter) لم تعد ضرورية ويمكن إخفاؤها. يمكنك حذف توابع التلقّي والضبط إذا جعلتها خاصة وطبقت الوصول المباشر إلى المتغيرات. | ||
== فوائد تطبيق الحل == | == فوائد تطبيق الحل == | ||
* إخفاء التوابع يجعل تطوير الشيفرة البرمجية أسهل. عند تغيير تابع خاص، تحتاج فقط إلى العناية بكيفية عدم كسر الصنف الحالي لأنك تعرف أنه لا يمكن استخدام التابع في أي مكان آخر. | * إخفاء التوابع يجعل تطوير الشيفرة البرمجية أسهل. عند تغيير تابع خاص، تحتاج فقط إلى العناية بكيفية عدم كسر الصنف الحالي لأنك تعرف أنه لا يمكن استخدام التابع في أي مكان آخر. | ||
* | * بجعل التوابع خاصة، فأنت تؤكد على أهمية الواجهة العامة للصنف وكذلك التوابع التي تظل عامة. | ||
== آلية الحل == | == آلية الحل == | ||
| سطر 34: | سطر 34: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Techniques]] | [[تصنيف:Refactoring Techniques]] | ||
[[تصنيف:Simplifying Method Calls]] | [[تصنيف:Refactoring Simplifying Method Calls]] | ||
المراجعة الحالية بتاريخ 08:36، 26 فبراير 2019
المشكلة
لا يُستخدم التابع من قِبل الأصناف الأخرى أو يستخدم فقط داخل التسلسل الهرمي للصنف الخاص به.
الحل
جعل التابع خاصًا أو محميًا.
مثال
قبل إعادة التصميم
لا يستخدم التابع ()aMethod من قبل أصناف أخرى غير الصنف Employee المعرف فيه:
بعد إعادة التصميم
جعل التابع ()aMethod خاصًّا ومحميًّا بإخفائه عن الأصناف الأخرى:
لم إعادة التصميم؟
في كثير من الأحيان، ترجع الحاجة إلى إخفاء توابع الحصول على القيم وضبطها إلى تطوير واجهة أكثر ثراءً توفر سلوكًا إضافيًا، خاصة إذا كنت بدأت بصنف يضيف أكثر قليلًا من مجرد تغليف البيانات.
مع وجود سلوك جديد مبنيٌ في الصنف، قد تجد أنَّ كلًا من توابع الجلب (getter) والضبط (setter) لم تعد ضرورية ويمكن إخفاؤها. يمكنك حذف توابع التلقّي والضبط إذا جعلتها خاصة وطبقت الوصول المباشر إلى المتغيرات.
فوائد تطبيق الحل
- إخفاء التوابع يجعل تطوير الشيفرة البرمجية أسهل. عند تغيير تابع خاص، تحتاج فقط إلى العناية بكيفية عدم كسر الصنف الحالي لأنك تعرف أنه لا يمكن استخدام التابع في أي مكان آخر.
- بجعل التوابع خاصة، فأنت تؤكد على أهمية الواجهة العامة للصنف وكذلك التوابع التي تظل عامة.
آلية الحل
- حاول بانتظام العثور على التوابع التي يمكن جعلها خاصة. يمكن أن يقدم تحليل الشيفرات الثابتة وتغطية اختبار الوحدة الجيدة خطوة كبيرة للأمام.
- اجعل كل تابع خاصًا قدر الإمكان.