نتائج البحث

تساعد عملية إعادة التصميم (refactoring) في توزيع المهام بشكل مثاليّ على الأصناف (classes) المختلفة في الشيفرة، وتضمن تقنيات الحل هذه طريقةً آمنةً لنقل المهام (functionality) ما بين الأصناف، وإنشاء أصناف جديدة وحماية تفاصيل عملية التنفيذ (implementation) من الوصول العام (public access)، وهذه التقنيات تشمل: نقل التابع (Move Method) المشكلة: استخدام التابع (method) في صنفٍ (class) ما أكثر من استخدامه في صنفه الأساسيّ. الحل: إنشاء تابعٍ جديدٍ في الصنف الأكثر استخدامًا لذلك التابع ونقل شيفرته إلى التابع الجديد، ثم تحويل الشيفرة ...

تساعد عملية إعادة التصميم (refactoring) في توزيع المهام بشكل مثاليّ على الأصناف (classes) المختلفة في الشيفرة، وتضمن تقنيات الحل هذه طريقةً آمنةً لنقل المهام (functionality) ما بين الأصناف، وإنشاء أصناف جديدة وحماية تفاصيل عملية التنفيذ (implementation) من الوصول العام (public access)، وهذه التقنيات تشمل: نقل التابع (Move Method) المشكلة: استخدام التابع (method) في صنفٍ (class) ما أكثر من استخدامه في صنفه الأساسيّ. الحل: إنشاء تابعٍ جديدٍ في الصنف الأكثر استخدامًا لذلك التابع ونقل شيفرته إلى التابع الجديد، ثم تحويل الشيفرة ...

المشكلة استخدام التابع (method) في صنفٍ (class) ما أكثر من استخدامه في صنفه الأساسيّ. الحل إنشاء تابعٍ جديدٍ في الصنف الأكثر استخدامًا لذلك التابع ونقل شيفرته إلى التابع الجديد، ثم تحويل الشيفرة في التابع الأصليّ إلى مرجعيّةٍ للتابع الجديد في الصنف الآخر أو حذفه كليَّا. مثال قبل إعادة التصميم يستخدِم الصنفُ Class2 التابعَ aMethod()‎ أكثر مما يستخدمه صنفه الأساسيّ Class1: يستخدِم الصنفُ Class2 التابعَ aMethod()‎ أكثر مما يستخدمه صنفه الأساسيّ Class1. بعد إعادة التصميم نُقِل التابع aMethod()‎ إلى الصنف ذي ...

توصيف المشكلة استخدام بعضُ التوابع (methods) بياناتِ الكائنات (objects) الأخرى أكثر ممّا تستخدم بياناتِها ذاتَها. أسبابها تحدث هذه المشكلة عقب نقل الحقول (fields) إلى أصناف البيانات (data class)، إذ من الأفضل نقلُ التوابع المستخدِمة لتلك الحقول لذلك الصنف أيضًا. وما الحل؟ لنضع بالحسبان القاعدة الآتية: يجب أن تبقى الأجزاء التي تتغيَّر بآنٍ واحدٍ في المكان ذاته معًاولتحقيق ذلك: نقلُ التوابع (move methods) إلى المكان الأنسب في الشيفرة. عندما يستخدِم جزءٌ فقط من التابع بياناتِ كائنٍ (object) آخر، فالأفضل استخراجُ تابعٍ ...

المشكلة استخدام الحقل (field) في صنفٍ (class) ما أكثر من استخدامه في صنفه الأساسيّ. الحل إنشاء حقلٍ في صنفٍ جديدٍ وإعادة توجيه (redirect) كلَّ ما يستخدم هذا الحقل إلى ذلك الصنف المُنشَأ. مثال قبل إعادة التصميم يستخدِم الصنفُ Class2 الحقلَ aField أكثر مما يستخدمه صنفه الأساسيّ Class1: يستخدِم الصنفُ Class2 الحقلَ aField أكثر مما يستخدمه صنفه الأساسيّ Class1. بعد إعادة التصميم نُقِل الحقل aField إلى الصنف ذي الاستخدام الأكثر له وهو الصنف Class2: نُقِل الحقل aField إلى الصنف ذي الاستخدام ...

المشكلة وجود صنفٍ (class) لا يقوم بأيّ مهمّة فعليّة ولا يُخطَّط لإضافة مهامٍ إليه لاحقًا. الحل نقل كافّة الميّزات (features) من هذا الصنف إلى صنفٍ آخر. مثال قبل إعادة التصميم يحتوي الصنف Person على حقلٍ واحدٍ باسم name وتابعٍٍ للحصول على رقم الهاتف getTelephoneNumber ولاشيء آخر، أمّا الصنف TelephoneNumber فهو يحتوي على حقلين باسم officeAreaCode و officeNumber بالإضافة إلى التابع السابق getTelephoneNumber، كما هو موضَّحٌ في مخطط الأصناف الآتي: الصنف Person يحتوي على حقلٍ واحدٍ باسم name وتابعٍٍ للحصول على ...

تجري عملية إعادة التصميم (refactoring) عبر عدّة خطواتٍ تُحدِث تغييرًا بسيطًا تدريجيًّا يجعل الشيفرة (مع كلِّ تغييرٍ) أفضل بقليلٍ، ولكنها لا توثر على أداء وفعاليّة البرنامج وتحافظ على استمرار عمله بشكلٍ سليمٍ، وتتلخص إعادة التصميم بالخطوات الآتية: الحصول على شيفرةٍ نظيفة (clean code) إن لم تصبح الشيفرة أنظف من بعد إعادة التصميم فهذا هدرٌ للوقت، ولكن ما السبب؟ يحدث كثيرًا أن تحيد عن سياق إعادة التصميم بتغييراتٍ تدريجيّة صغيرةٍ لتتجه نحو إجراء تغييرٍ كبيرٍ واحدٍ! وهذا خطأ ومن السهل الوقوع ...

إنشاء التوابع تستهدف إعادة التصميم بشكل رئيسيٍّ إنشاء التوابع الصحيحة المناسبة، إذ تكون التوابع الطويلة سببًا للمشاكل في كثيرٍ من الحالات، وتجعل شيفرات بعض التوابع منطق التنفيذ (execution logic) غامضًا ويصبح التابع بهذا عصيَّ الفهم من جهةٍ وصعب التغييرٍ من جهة ثانية. يشمل هذا القسم من الحلول كلَّ ما يتعلق بالتوابع وإزالة التكرار (duplicates) في الشيفرة ليسمح بإجراء التطويرات المستقبليّة، وهذه التقنيات هي: استخراج التوابع (Extract Methods): والتي تتمثل بوجود أجزاء من الشيفرة يُمكن عزلها وتجميعها سويةً. دمج التوابع (Inline ...

المشكلة وجود صنفٍ (class) واحدٍ يقوم بمهامٍ عديدةٍ يمكن توزيعها على صنفين. الحل إنشاء صنفٍ جديدٍ ونقل بعض الحقول (fields) والتوابع (methods) إليه، والتي تتعلَّق بالمهام الوظيفيّة (functionality) لهذا الصنف الجديد. مثال قبل إعادة التصميم يحتوي الصنف Person على عددٍ من الحقول كاسم الشخص (name) ورمز منطقة المكتب (officeAreaCode) ورقمه (officeNumber)، وتابعًا للحصول على هذا الرقم باسم getTelephoneNumber، كما في مخطط الأصناف الآتي: الصنف Person يحتوي على عددٍ من الحقول كاسم الشخص (name) ورمز منطقة المكتب (officeAreaCode) ورقمه (officeNumber)، وتابعًا ...

نحتاج إلى إعادة التصميم (قاعدة المرات الثلاث): عند قيامك بأيّة مهمةٍ للمرّة الأولى، فالمهم هو إنجازها والحصول على النتيجة وحسب. لدى قيامك بمهمةٍ مشابهةٍ للمرّة الثانية قد ترفض بادئ الأمر فكرة التكرار ولكنك ستجد نفسك تقوم بنفس العمل! عند قيامك بالمهمة للمرّة الثالثة، ستحتاج إعادة التصميم. عند إضافة ميّزةٍ (feature) جديدة تساعد عملية إعادة التصميم (refactoring) على فهم شيفرات المبرمجين الآخرين بشكلٍ أفضل، وعند العمل على الشيفرة غير الجيدة لأحدهم فعليك بإعادة تصميمها أولًا، وهذا ضروريٌّ إذ يصبح التحكُّم بالشيفرة ...