نتائج البحث
اذهب إلى التنقل
اذهب إلى البحث
تبسيط التعابير الشرطية (Simplifying Conditional Expressions)
تزداد البنية المنطقية للشروط تعقيدًا مع مرور الوقت، لذا هنالك الكثير من التقنيات لمواجهة هذا التعقيد وتبسيطه وهي: تجزئة الشَرطيات (Decompose Conditional) المشكلة: يوجد شَرط مُعقد (if-then/else أو switch). الحل: فصل الأجزاء المعقدة من الشَرط إلى توابع منفصلة: الشرط، و then و else. توحيد التعبير الشرطي (Consolidate Conditional Expression) المشكلة: وجود عدة شروط تؤدي إلى نفس النتيجة أو الإجراء. الحل: توحيد جميع هذه الشروط في تعبير وحيد. توحيد الأجزاء الشرطية المكررة (Consolidate Duplicate Conditional Fragments) المشكلة: شيفرة برمجية متطابقة موجودة في جميع فروع الشَرطيات. الحل: ...
توحيد التعبير الشرطي (Consolidate Conditional Expression)
المشكلة وجود عدة شروط تؤدي إلى نفس النتيجة أو الإجراء. الحل توحيد جميع هذه الشروط في تعبير وحيد. مثال قبل إعادة التصميم وجود عدة شروط يتم التحقق منها في الشيفرة: في لغة Java: double disabilityAmount() {
if (seniority < 2) {
return 0;
}
if (monthsDisabled > 12) {
return 0;
}
if (isPartTime) {
return 0;
}
// حساب مقدار العجز
//...
}
في ...
تقنيات إعادة التصميم (Refactoring Techniques)
إنشاء التوابع تستهدف إعادة التصميم بشكل رئيسيٍّ إنشاء التوابع الصحيحة المناسبة، إذ تكون التوابع الطويلة سببًا للمشاكل في كثيرٍ من الحالات، وتجعل شيفرات بعض التوابع منطق التنفيذ (execution logic) غامضًا ويصبح التابع بهذا عصيَّ الفهم من جهةٍ وصعب التغييرٍ من جهة ثانية. يشمل هذا القسم من الحلول كلَّ ما يتعلق بالتوابع وإزالة التكرار (duplicates) في الشيفرة ليسمح بإجراء التطويرات المستقبليّة، وهذه التقنيات هي: استخراج التوابع (Extract Methods): والتي تتمثل بوجود أجزاء من الشيفرة يُمكن عزلها وتجميعها سويةً. دمج التوابع (Inline ...
تجزئة الشَرطيات (Decompose Conditional)
المشكلة يوجد شَرط مُعقد (if-then/else أو switch). الحل فصل الأجزاء المعقدة من الشَرط إلى توابع منفصلة: الشرط، then و else. مثال قبل إعادة التصميم وجود شرط معقد ناتج عن دمج شرطين باستعمال المعامل || الثنائي في البنية if: في لغة Java: if (date.before(SUMMER_START) || date.after(SUMMER_END)) {
charge = quantity * winterRate + winterServiceCharge;
}
else {
charge = quantity * summerRate;
}
في لغة C#: if (date < SUMMER_START || date > SUMMER_END)
{
charge = quantity * winterRate + winterServiceCharge;
}
else ...
تبديل الشرطيات بالتعدديّة الشكليّة (Replace Conditional with Polymorphism)
المشكلة وجود شروط تنفِّذ إجراءات مختلفة اعتمادًا على نوع الكائن أو خصائصه. الحل إنشاء أصناف فرعية مطابقة لفروع البنية الشرطية. ويُنشأ فيها تابع مشترك وتُنقل إليه الشيفرة البرمجية من الفرع المقابل من الشرطية. ثم تُستبدل البنية الشرطية باستدعاء التابع المناسب. وينتج عن ذلك تنفيذ سليم يتحقق من خلال التعدديّة الشكليّة اعتمادًا على صنف الكائن. مثال قبل إعادة التصميم الصنف Bird يحتوي على التابع getSpeed الذي باستعمال البنية الشرطية switch من النوع type لحساب السرعة بناءً على قيمته: في لغة Java: ...
توحيد الأجزاء الشرطية المكررة (Consolidate Duplicate Conditional Fragments)
المشكلة شيفرة برمجية متطابقة موجودة في جميع فروع الشَرطيات. الحل نقل الشيفرة البرمجية خارج الشَرطية. مثال قبل إعادة التصميم استدعاء وتنفيذ الدالة ()send في نهاية جميع فروع الكتلة if الشرطية سواءً أكان الشرط محققًا أم لا: في لغة Java: if (isSpecialDeal()) {
total = price * 0.95;
send();
}
else {
total = price * 0.98;
send();
}
في لغة C#: if (IsSpecialDeal())
{
total = price * 0.95;
Send();
}
else
{
total = price * 0.98;
...
تبديل الشرطيات المتداخلة بعبارات الحماية (Replace Nested Conditional with Guard Clauses
المشكلة وجود مجموعة متداخلة من الشروط وصعوبة تحديد التدفق الطبيعي لتنفيذ الشيفرة البرمجية. الحل عزل جميع الاختبارات الخاصة والحالات الطرفية في عبارات منفصلة ووضعها قبل الاختبارات الرئيسية. من الناحية المثالية، يجب أن يكون لديك قائمة "مسطحة" من الشروط، واحدةً تلو الأخرى. مثال قبل إعادة التصميم يوجد لدينا الدالة ()getPayAmount التي تتحقق من القيمة المُستدعاة معها عبر عدد من الشروط المتشعبة - مع استعمال المتغير result للحصول على النتيجة وإعادتها في النهاية - مما يجعل معرفة تدفق ومسار الدالة أمرًا معقدًا: ...
تبسيط استدعاءات التوابع (Simplifying Method Calls)
تجعل التقنيات التي سيشار إليها في هذا القسم استدعاءات التوابع أبسط وأسهل للفهم والاستيعاب. سيؤدي ذلك بدوره إلى تبسيط الواجهات للتفاعل بين الأصناف. هذه التقنيات هي: إعادة تسمية التوابع (Rename Method) المشكلة: لا يعبِّر اسم التابع عن ما يقوم به. الحل: إعادة تسمية التابع. إضافة المعاملات (Add Parameter) المشكلة: لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات. الحل: إنشاء معامل جديد لتمرير البيانات الضرورية. حذف المعاملات (Remove Parameter) المشكلة: لا يُستخدم معاملٌ ما في متن التابع. الحل: إزالة المعامل غير ...
for في JavaScript
التعبير البرمجي for يُنشِئ حلقة تكرار تتألف من ثلاثة تعبيرات برمجية اختيارية تحيط بها أقواس وتفصل بينها فواصل منقوطة، ويليها تعبيرٌ برمجيٌ (وعادةً يكون قسمًا كتليًا [block statement]) سيُنفَّذ في كل تكرار للحلقة. البنية العامة for ([initialization]; [condition]; [final-expression])
statement
initialization تعبير (يتضمن تعابير الإسناد) أو تصريح عن متغير، ويُستخدَم عادةً لتهيئة متغير العدّاد؛ وهذا التعبير قد يُصرِّح اختياريًا عن متغيرات جديدة باستخدام الكلمة المحجوزة var؛ وهذه المتغيرات ليست محليةً وتابعةً لحلقة التكرار، وإنما ستكون موجودةً في نفس ...
خطوات إعادة التصميم (Refactoring)
تجري عملية إعادة التصميم (refactoring) عبر عدّة خطواتٍ تُحدِث تغييرًا بسيطًا تدريجيًّا يجعل الشيفرة (مع كلِّ تغييرٍ) أفضل بقليلٍ، ولكنها لا توثر على أداء وفعاليّة البرنامج وتحافظ على استمرار عمله بشكلٍ سليمٍ، وتتلخص إعادة التصميم بالخطوات الآتية: الحصول على شيفرةٍ نظيفة (clean code) إن لم تصبح الشيفرة أنظف من بعد إعادة التصميم فهذا هدرٌ للوقت، ولكن ما السبب؟ يحدث كثيرًا أن تحيد عن سياق إعادة التصميم بتغييراتٍ تدريجيّة صغيرةٍ لتتجه نحو إجراء تغييرٍ كبيرٍ واحدٍ! وهذا خطأ ومن السهل الوقوع ...