نتائج البحث

توصيف المشكلة تظهر المشكلة بعدَّة جوانب: استخدام الحقول الأساسيّة (primitives) بدلًا من الكائنات (objects) لأداء المهامّ البسيطة (مثل: عمليات العملة [currency] والمجالات [ranges] والسلاسل النصية [strings] المُخصَّصة للأرقام الهاتفية، …إلخ.). استخدام الثوابت (constants) لترميز المعلومات (مثل استخدام الثابت USER_ADMIN_ROLE = 1 للدلالة على المستخدمين ذوي الصلاحيّات الإداريّة). استخدام الثوابت النصيّة (string constants) كأسماءٍ للحقول (fields) في مصفوفات البيانات (data arrays). أسبابها تنشأ هذه المشكلة بسبب العبارة المُدمِّرة التي يفكّر بها المبرمجون بلحظة ضعفٍ: "حقلٌ واحدٌ فقط، ولتخزين معلومةٍ بسيطةٍ وحسب!"ولأنهم ...

المشكلة هل لديك تابعٌ يُعيد قيمةً ما ولكن يغيِّر أيضا شيئًا ما داخل الكائن؟ الحل تقسيم التابع إلى تابعَين منفصلَين. كما يمكن أن نتوقع، يجب على أحدهما أن يعيد القيمة ويُغيِّر الآخر الكائن. مثال قبل إعادة التصميم ينفذ التابع ()getTotlaOutstandingAndSetReadyForSummaries في الصنف Customer مهمتين، إذ يعيد قيمة ويضبط قيمة أخرى في الكائن: تابع يُعيد قيمة ويغيِّر شيئًا ما داخل الكائن. بعد إعادة التصميم فصل التابع التابع ()getTotlaOutstandingAndSetReadyForSummaries إلى تابعين هما: الأول ()getTotlaOutstanding لجلب قيمة، والآخر ()setReadyForSummaries لضبط حالةٍ في الكائن: ...

تجعل التقنيات التي سيشار إليها في هذا القسم استدعاءات التوابع أبسط وأسهل للفهم والاستيعاب. سيؤدي ذلك بدوره إلى تبسيط الواجهات للتفاعل بين الأصناف. هذه التقنيات هي: إعادة تسمية التوابع (Rename Method) المشكلة: لا يعبِّر اسم التابع عن ما يقوم به. الحل: إعادة تسمية التابع. إضافة المعاملات (Add Parameter) المشكلة: لا يملك التابع بيانات كافية لتنفيذ بعض الإجراءات. الحل: إنشاء معامل جديد لتمرير البيانات الضرورية. حذف المعاملات (Remove Parameter) المشكلة: لا يُستخدم معاملٌ ما في متن التابع. الحل: إزالة المعامل غير ...

توصيف المشكلة تكرار مجموعةٍ من المتغيِّرات (variables) (كتلك المُستخدَمة كمعاملاتٍ [parameters] للربط مع قاعدة البيانات مثلًا) بشكلٍ متطابقٍ تمامًا في عدّة أجزاء من الشيفرة، إذ يجب تحويل تلك المجموعات إلى أصنافها (classes) الخاصّة بها. أسبابها تُعزى المشكلة عمومًا للبُنية (structure) البرمجيّة الضعيفة (أو ما يُعرف بمصطلح copypasta programming)، وللتحقُّقِ من وجود هذه المشكلة بالشيفرة احذف إحدى القيم، فإنْ حدث خللٌ نتيجة الحذف فالمشكلة قائمة ويجب علاجها، وإلّا فتلك إشارةٌ حسنةٌ ومن المحبَّذ تجميعُ هذه المتغيِّرات في كائنٍ واحدٍ. وما الحل؟ ...

المشكلة احتواء الصنف (class) على العديد من التوابع (methods) التي تنقل (delegate) سياق البرنامج إلى كائنات (objects) أخرى. الحل حذف تلك التوابع وإجبار العميل (client) على الاستدعاء المباشر للتوابع النهائية (التي سيصل إليها بالنهاية وتحتوي المهام الفعليّة). مثال قبل إعادة التصميم يتعامل صنف العميل (client class) مع صنفٍ واحدٍ فقط وهو الصنف Person، والذي بدوره يستدعي كائنًا من صنفٍ آخر باسم Department دون أن يكون العميل على علمٍ بتفاصيل ذلك الاستدعاء، كما هو واضح في مخطط الأصناف الآتي: مخطط يوضح ...

تساعد تقنيات إعادة التصميم هذه بالتعامل مع البيانات، وتبديل أصناف ذات وظائف كثيرة مكان الأنواع الأساسية (primitives). نتيجة أخرى مهمة نحصل عليها بتطبيق هذه التقنيات هي فك ارتباطات صنف مما يجعل الصنف قابلًا للنقل وإعادة الاستعمال. وهذه التقنيات هي: التغليف الداخلي للحقول (Self Encapsulate Fields) المشكلة: الوصول المباشر إلى الحقول الخاصّة داخل الصنف. الحل: إنشاء تابعي الجلب (getter) والضبط (setter) للحقل الخاصّ ومنع الوصول إليه إلا عبرهما. تبديل قيم البيانات إلى كائنات (Replace Data Values with Objects) المشكلة: وجود حقلٍ ...

المشكلة لديك حقل عام. الحل جعل الحقل خاصًّا وإنشاء توابع وصول له. مثال قبل إعادة التصميم وجود الحقل العام name في الصنف Person: في لغة Java: class Person { public String name; } في لغة C#‎: class Person { public string name; } في لغة PHP: public $name; في لغة TypeScript: class Person { name: string; } بعد إعادة التصميم جعل الحقل name خاصًّا وإنشاء تابع جلب getName وضبط setName له: في لغة Java: class Person { private String name; public ...

المشكلة وجود شروط تنفِّذ إجراءات مختلفة اعتمادًا على نوع الكائن أو خصائصه. الحل إنشاء أصناف فرعية مطابقة لفروع البنية الشرطية. ويُنشأ فيها تابع مشترك وتُنقل إليه الشيفرة البرمجية من الفرع المقابل من الشرطية. ثم تُستبدل البنية الشرطية باستدعاء التابع المناسب. وينتج عن ذلك تنفيذ سليم يتحقق من خلال التعدديّة الشكليّة اعتمادًا على صنف الكائن. مثال قبل إعادة التصميم الصنف Bird يحتوي على التابع getSpeed الذي باستعمال البنية الشرطية switch من النوع type لحساب السرعة بناءً على قيمته: في لغة Java: ...

تزداد البنية المنطقية للشروط تعقيدًا مع مرور الوقت، لذا هنالك الكثير من التقنيات لمواجهة هذا التعقيد وتبسيطه وهي: تجزئة الشَرطيات (Decompose Conditional) المشكلة: يوجد شَرط مُعقد (if-then/else أو switch). الحل: فصل الأجزاء المعقدة من الشَرط إلى توابع منفصلة: الشرط، و then و else. توحيد التعبير الشرطي (Consolidate Conditional Expression) المشكلة: وجود عدة شروط تؤدي إلى نفس النتيجة أو الإجراء. الحل: توحيد جميع هذه الشروط في تعبير وحيد. توحيد الأجزاء الشرطية المكررة (Consolidate Duplicate Conditional Fragments) المشكلة: شيفرة برمجية متطابقة موجودة في جميع فروع الشَرطيات. الحل: ...

المشكلة هل بيانات النطاق المخزَّنة في أصناف هي المسؤولة عن واجهة المستخدم الرسومية (GUI)؟ إذًا، إليك الحل. الحل فصل البيانات في أصناف منفصلة لضمان الاتصال والتزامن بين صنف النطاق وواجهة المستخدم الرسومية (GUI). مثال قبل إعادة التصميم إليك المخطط التالي لبيانات نطاق مخزَّنة في أصناف والمسؤولة عن الواجهة الرسومية: بيانات النطاق مخزَّنة في أصناف. بعد إعادة التصميم يصبح المخطط السابق بالشكل التالي بعد إعادة التصميم: فصل البيانات في أصناف منفصلة لضمان الاتصال والتزامن بين صنف النطاق وواجهة المستخدم الرسومية. لم ...