نتائج البحث

المشكلة لديك حقل عام. الحل جعل الحقل خاصًّا وإنشاء توابع وصول له. مثال قبل إعادة التصميم وجود الحقل العام 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 ...

المشكلة يعيد التابع قيمة خاصة تشير إلى خطأ. الحل إطلاق استثناء بدلًا من ذلك. مثال قبل إعادة التصميم يعيد التابع ()withdraw القيمة 1- التي تمثِّل خطأً إن تحقق شرط محدَّد: في لغة Java: int withdraw(int amount) { if (amount > _balance) { return -1; } else { balance -= amount; return 0; } } في لغة C#‎: int Withdraw(int amount) { if (amount > _balance) { ...

المشكلة الحاجة إلى بعض التوابع (methods) غير الموجودة في الصنف المساعد (utility class)، ومن غير الممكن إضافتها إلى ذلك الصنف. الحل إنشاء صنفٍ (class) جديدٍ يحتوي التوابع اللازمة، وجعله كصنف تغليفٍ (wrapper) للصنف المساعد أو كصنفٍ فرعيٍّ (subclass) له. مثال قبل إعادة التصميم يعتمد صنف العميل ClientClass على الصنف المساعد Date ولكنّه بحاجة إلى بعض التوابع غير الموجودة فيه (كتابع الحصول على اليوم التالي مثلًا): الصنف العميل ClientClass الذي يعتمد على الصنف المساعد Date. بعد إعادة التصميم أصبح هنالك صنف ...

يملك التجريد (Abstraction) تقنيات إعادة التصميم الخاصة به والمرتبطة بشكل أساسي بوظيفة النقل على طول التسلسل الهرمي لوراثة الصنف (class inheritance hierarchy)، وبإنشاء أصناف وواجهات جديدة، وبتبديل التفويض مكان الوراثة أو العكس. تقنيات هذا القسم هي: استخراج الأصناف الفرعية (Extract Subclass) المشكلة: يكون للصنف ميزات تستعمل فقط في حالات معينة. الحل: إنشاء صنف فرعي واستخدامه في هذه الحالات. استخراج الأصناف الفائقة (Extract Superclass) المشكلة: وجود صنفين لهما حقول وتوابع مشتركة. الحل: إنشاء صنف أب مشترك لهما ونقل جميع الحقول والتوابع ...

المشكلة وجود أجزاء من الشيفرة يُمكن عزلها وتجميعها سويةً. الحل نقل الشيفرة إلى تابعٍ (method) أو دالةٍ (function) جديدة والاستعاضة عن الجزء (بمكانه السابق) باستدعاءٍ لهذا التابع الجديد. مثال قبل إعادة التصميم نلاحظ وجود جزء من الشيفرة لطباعة بعض البيانات (التفاصيل)، والتي يمكن عزلها بتابعٍ جديد، الشيفرة قبل إعادة التصميم بالشكل: في لغة Java: void printOwing() { printBanner(); // طباعة التفاصيل System.out.println("name: " + name); System.out.println("amount: " + getOutstanding()); } في لغة #C: void PrintOwing() { PrintBanner(); ...

المشكلة أن يكون محتوى التابع (method body) بسيطًا وواضحًا أكثر من التابع بحدِّ ذاته، ويمكن عندئذٍ الاستغناء عنه. الحل نقل الشيفرة الموجودة في التابع (محتوى التابع) إلى مواقع استدعائه، وحذف التابع برمته إذ لا داعي له. مثال قبل إعادة التصميم نلاحظ أن محتوى التابع moreThanFiveLateDeliveries()‎ واضحٌ وبسيطٌ لدرجةٍ تجعل الاستغناء عنه ممكنًا: في لغة Java: class PizzaDelivery { //... int getRating() { return moreThanFiveLateDeliveries() ? 2 : 1; } boolean moreThanFiveLateDeliveries() { ...

المشكلة وجود صنفان يحتاج كل منهما إلى استخدام ميزات الآخر، ولكن الاقتران بينهما أحادي الاتجاه فقط. الحل إضافة الاقتران المفقود إلى الصنف الذي يحتاج إليه. مثال قبل إعادة التصميم يحتاج الصنفان Customer و Order أحدهما الآخر ولكن الاقتران بينهما أحادي الاتجاه: الاقتران بين الصنفين أحادي الاتجاه فقط. بعد إعادة التصميم إضافة الاقتران الناقص إلى الصنف Customer: الاقتران المفقود مُضاف إلى الصنف الذي يحتاج إليه. لم إعادة التصميم؟ في الأصل، كان اقتران الأصناف أحادي الاتجاه. ولكن مع الوقت، احتاجت شيفرة العميل ...

توصيف المشكلة تحتوي الحقول المؤقَّتة على قيمٍ (وتُستخدَم وفقًا لها في الكائنات [objects]) ضمن شروطٍ مُحدَّدة، وتبقى فارغةً عند عدم تحقٌّق تلك الشروط. أسبابها تُخصَّصُ الحقول المؤقتة لاستخدامها في الخوارزميات التي تتطلَّب عددًا كبيرًا من المُدخلات (inputs)، فبدلًا من إنشاء الكثير من المعاملات في التابع (method parameters) يلجأ المُبرمِج لإنشاء حقولٍ مؤقَّتة لاحتواء البيانات المطلوبة في الصنف (class)، وبهذا فإنّ استخدام تلك الحقول لا يتعدّى تنفيذَ الخوارزميّة المُحدَّدة (ولا وظيفة أخرى لها خارج ذلك النطاق)، ويجعل وجودُ تلك الحقول من ...

المشكلة جلب عدة قيم من أحد الكائنات، ثم تمريرها كمعاملات إلى أحد التوابع. الحل حاول تمرير الكائن بالكامل بدلًا من ذلك. مثال قبل إعادة التصميم جلب قيمة درجة الحرارة المنخفضة low والمرتفعة high من الكائن daysTempRange ثم تمريرهما إلى التابع ()withinTange: في لغة Java: int low = daysTempRange.getLow(); int high = daysTempRange.getHigh(); boolean withinPlan = plan.withinRange(low, high); في لغة C#‎: int low = daysTempRange.GetLow(); int high = daysTempRange.GetHigh(); bool withinPlan = plan.WithinRange(low, high); في لغة PHP: $low = $daysTempRange->getLow(); $high = $daysTempRange->getHigh(); $withinPlan = $plan->withinRange($low, $high); في لغة Python: ...

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

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

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

المشكلة وجود متغيِّرٍ مؤقَّت (temporary) لحفظ قيمة تعبيرٍ (expression) بسيطٍ ولا شيء آخر سواه. الحل تبديل كلُّ مرجعيّةٍ (reference) للمتغيِّر ليحلَّ محلَّها التعبيرُ نفسه. مثال قبل إعادة التصميم نلاحظ في الشيفرة الآتية وجود متغيِّرٍ مؤقتٍ باسم basePrice لتخزين القيمة الناتجة عن تعبير استدعاء التابع order.basePrice()‎، والذي سيُستخدَم في التعليمة التالية لتعريفه: في لغة Java: boolean hasDiscount(Order order) { double basePrice = order.basePrice(); return basePrice > 1000; } في لغة #C: bool HasDiscount(Order order) { double basePrice = order.BasePrice(); return ...

ملاحظة قبل البدء إنّ مشكلة تغيير الأصناف المتعدِّدة هي المشكلة المعاكسة تمامًا لمشكلة التغيير المتشعِّب (Divergent Change)، إذ إنّ التغيير المتشعِّب هو مجموع التغييرات الكثيرة التي تُجرَى في صنفٍ (class) واحدٍ، أما تغيير الأصناف المتعدِّدة فهو تغييرٌ واحدٌ يُجرَى في العديد من الأصناف. توصيف المشكلة يتطلَّبُ أيُّ تعديلٍ تقوم به إجراءَ تغييراتٍ طفيفةٍ بأصناف (classes) متفرِّقة. أسبابها توزيع مهمةٍ واحدةٍ على الكثير من الأصناف، ويحدث هذا نتيجةً للتطبيق المفرط للتغيير المُتشعِّب (Divergent Change). وما الحل؟ نقل سلوك (behaviour) الأصناف إلى ...

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

المشكلة الحاجة إلى تابعٍ غير موجودٍ في الصنف المساعد (utility class) ومن غير الممكن إضافته إلى ذلك الصنف. الحل إضافة التابع المطلوب إلى صنف العميل (client class) وتمرير كائنٍ (object) من الصنف المساعد إليه كوسيط (argument). مثال قبل إعادة التصميم يحتوي الصنف Report تابعًا باسم sendReport والذي يستخدم الصنف المساعد Date لإنشاء تاريخ اليوم التالي عبر إضافة القيمة 1 إلى اليوم الحالي، كما يلي: في لغة Java: class Report { //... void sendReport() { Date ...

توصيف المشكلة وجود أصنافٍ (classes) أو توابعَ (methods) أو حقولٍ (fields) أو معاملاتٍ (parameters) غير مُستخدَمة في الشيفرة. أسبابها إنشاء عناصرَ إضافيّةٍ "قد" يحتاجها المبرمج مستقبلًا لميّزات يُخطِّط لها (وقد لا تُنفَّذ أصلًا)، وغير مستخدمةٍ بالوقت الحاليّ، مما يجعل الشيفرة أكثر صعوبةً بالفهم والدعم. وما الحل؟ هدم الهيكليّة الهرميّة (collapse hierarchy) لإزالة الأصناف المُجرَّدة (abstract classes) غير المُستخدَمة. دمج الأصناف (inline classes) للحدُّ من عمليات تفويض المهامّ (delegation) غير الضروريّة لصنفٍ آخر. دمج التوابع (inline methods) للتخلُّص من التوابع عديمة ...

المشكلة إسناد قيمةٍ ما إلى أحد المعاملات (parameter) داخل التابع (method body). الحل استخدام متغيِّرٍ محليٍّ (local variable) بدلًا من المعامل. مثال قبل إعادة التصميم نلاحظ وجود عمليّة إسنادٍ (من بعد الإنقاص بمقدار 2) إلى معامل التابع الوارد باسم inputVal: في لغة Java: int discount(int inputVal, int quantity) { if (inputVal > 50) { inputVal -= 2; } //... } في لغة #C: int Discount(int inputVal, int quantity) { if (inputVal > 50) ...

المشكلة في التسلسل الهرمي لصنف، يكون صنفٌ فرعي هو عمليًا نفس صنفه الأب. الحل دمج الصنف الفرعي والصنف الأب. مثال قبل إعادة التصميم الصنف الفرعي Salesman هو عمليًّا نفس الصنف Employee له: الصنفٌ الفرعي هو عمليًا نفس صنفه الأب. بعد إعادة التصميم دمج الصنف الفرعي Salesman في الصنف الأب: دمج الصنف الفرعي والصنف الأب. لم إعادة التصميم؟ قد يؤدي نمو البرنامج مع مرور الوقت إلى أن يصبح كلٌ من الصنف الفرعي والصنف الأب تقريبًا نفس الشيء. فتُزال ميزة من الصنف ...

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

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

المشكلة هل يستخدم الحقل في بعض الأصناف الفرعية فقط؟ الحل نقل الحقل إلى هذه الأصناف الفرعية. مثال قبل إعادة التصميم يُستخدَم الحقل fuel الموجود في الصنف Unit الأب في صنف فرعي واحد فقط الذي هو Tank: يستخدم الحقل في بعض الأصناف الفرعية فقط. بعد إعادة التصميم نقل الحقل من الصنف الأب إلى الصنف الفرعي المستخدم فيه: نقل الحقل إلى هذه الأصناف الفرعية. لم إعادة التصميم؟ على الرغم من أنه كان من المقرر استخدام حقل بشكل عام لجميع الأصناف، في الواقع ...

المشكلة لا يعبِّر اسم التابع عن ما يقوم به. الحل إعادة تسمية التابع. مثال قبل إعادة التصميم لا يفسر اسم التابع ()getsnm في الصنف Customer ما يقوم به. لا يفسر اسم التابع ما يقوم به. بعد إعادة التصميم إعادة تسمية التابع ()getsnm إلى ()getSecondName الذي يصف ما يقوم به. يفسر اسم التابع ما يقوم به. لم إعادة التصميم؟ ربما كانت تسمية تابعٍ ما سيئة من البداية - على سبيل المثال، أنشأ شخصٌ ما التابع في عجلة ولم يهتم كفاية بتسميته ...

المشكلة وجود تابعٍ طويلٍ بالكثير من المتغيِّرات المحليّة (local variables) المتداخلة والتي تحول دون تطبيق تقنية الحل باستخراج التابع (extract method). الحل نقل التابع إلى صنفٍ (class) مستقلٍ بحيث تصبح متغيِّراته المحليّة حقولًا (fields) لهذا الصنف، وتقسيم التابع بعد ذلك إلى عدّة توابع أصغر في الصنف ذاته. مثال قبل إعادة التصميم نلاحظ وجود العديد من المتغيِّرات المحليّة في التابع price()‎ بالإضافة إلى عملياتٍ أخرى قد تكون طويلةً ومعقَّدة: في لغة Java: class Order { //... public double price() ...

المشكلة وجود اقتران ثنائي الاتجاه (bidirectional association) بين الأصناف، ولكن لا يستخدم أحد الأصناف الميزات الأخرى. الحل إزالة الاقتران غير المستخدم. مثال قبل إعادة التصميم وجود اقتران ثنائي الاتجاه بين الصنفين Order و Customer، ولكن لا يستخدم أحدهما ميزات الآخر: وجود اقتران ثنائي الاتجاه بين الصنفين Order و Customer. بعد إعادة التصميم يحتاج الصنفان Customer و Order أحدهما الآخر ولكن الاقتران بينهما أحادي الاتجاه: وجود اقتران ثنائي الاتجاه بين الصنفين Order و Customer. لم إعادة التصميم؟ يكون من الصعب المحافظة على الاقتران ثنائي الاتجاه ...

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

المشكلة وجود تعبيرٍ (expression) معقِّد يصعُب فهمه. الحل وضع ناتج التعبير أو جزءٍ منه في متغيِّرات (variables) واضحةٍ تُسهِّل الفهم. مثال قبل إعادة التصميم نلاحظ وجود تعبيرٍ شرطيٍّ (conditional expression) معقَّدٍ وبعدّة أجزاء كما في الشيفرة الآتية: في لغة Java: void renderBanner() { if ((platform.toUpperCase().indexOf("MAC") > -1) && (browser.toUpperCase().indexOf("IE") > -1) && wasInitialized() && resize > 0 ) { // افعل شيئًا ...

المشكلة تحتوي الأصناف الفرعية على مُنشِئات لها شيفرة متطابقة في أغلبها. الحل إنشاء مُنشئ صنف أب ونقل الشيفرة المماثلة في الأصناف الفرعية إليه. استدعاء مُنشئ الصنف الأب في مُنشِئات الصنف الفرعي. مثال قبل إعادة التصميم احتواء الصنف الفرعي Manager المشتق من الصنف Employee على منشئ متطابق بنسبة كبيرة: في لغة Java: class Manager extends Employee { public Manager(String name, String id, int grade) { this.name = name; this.id = id; ...

توصيف المشكلة تنتُج هذه المشكلة عن احتواء شيفرة التابع على الكثير من الأسطر؛ فهو أمرٌ يدعو للتساؤل حقًا إن كان التابع بأكثر من 10 أسطر! لِمَ؟ أسبابها إنَّ ما يحدث دائمًا أنْ يُضاف للتابع لا أن يُحذَف منه! وذلك لسهولة كتابة الإضافات للشيفرة مقارنةً مع قراءتها، ولن تظهر هذه المشكلة واضحةً إلا بعد تفاقمها ووصولها لحدِ لا يُحتمَل، وكذلك يجد المبرمج أنَّ كتابة تابعٍ جديدٍ أكثرُ مشقّةً من الإضافة لتابعٍ موجودٍ مسبقًا، إذ يفكر: "هما سطران وحسب، ولا داعي لتخصيص ...

المشكلة يوجد شَرط مُعقد (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 ...

المشكلة هل السلوك المُنفَّذ في الصنف الأب مُستخدمٌ في صنف فرعي واحد فقط (أو أكثر)؟ الحل نقل هذا السلوك إلى الأصناف الفرعية. مثال قبل إعادة التصميم التابع ()getFuel الموجود في الصنف Unit الأب مُستخدم في صنف فرعي واحد فقط الذي هو Tank: التابع الموجود في الصنف الأب مُستخدم في صنف فرعي واحد فقط. بعد إعادة التصميم نقل التابع ()getFuel من الصنف الأب إلى الصنف الفرعي المستخدم فيه: نقل هذا التابع إلى الصنف الفرعي الذي يُستخدم فيه. لم إعادة التصميم؟ في ...

من مشاكل الشيفرات أيضًا التطبيقُ الخطأ وغير المكتمل لمبادئ البرمجة كائنية التوجّه (Object-Oriented)، مثل: استخدام الأصناف البديلة (alternative) ذات الواجهات (interfaces) المختلفة المشكلة: التطابق بالمهام ما بين صنفين ولكن بأسماءٍ مختلفةٍ لتوابعهما. الحل: حذف أحد الصنفين بعد تنفيذ إحدى الحلول الآتية: إعادة تسمية التوابع (methods) لتصبح متطابقةً بكافّة الأصناف البديلة، أو توحيد التوقيع (signature) وتعريف الاستخدام ما بين التوابع (إمّا بنقل التابع أو إضافة المعاملات أو دمج التوابع عبر المعاملات)، أو استخراج صنفٍ أعلى وجعلهما صنفين فرعيين له (إن كان التطابق جزئيًا). الوراثة الفائضة (refused bequest) ...

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

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

المشكلة وجود متغيِّرٍ محليّ يُستخدَم لتخزين عدّة قيمٍ مؤقتةٍ (مرحليّة) داخل التابع. الحل استخدام متغيِّراتٍ منفصلةٍ ومستقلّةٍ للقيم المختلفة، بحيث يكون كلَُ متغيِّرٍ مسؤولًا عن تخزين البيانات لمهمةٍ واحدةٍ فقط. مثال قبل إعادة التصميم نلاحظ في الشيفرة الآتية استخدام المتغيِّر temp لتخزين ناتج كلِّ من تعبيريّ المحيط والمساحة: في لغة Java: double temp = 2 * (height + width); System.out.println(temp); temp = height * width; System.out.println(temp); في لغة #C: double temp = 2 * (height + width); Console.WriteLine(temp); temp = height * width; Console.WriteLine(temp); في لغة PHP: $temp ...

ما هو رمز النوع (type code)؟ يحدث رمز النوع عندما يوجد مجموعة من الأرقام أو السلاسل النصية التي تشكل قائمة بالقيم المسموح بها لبعض العناصر بدلًا من استخدام نوع بيانات منفصل. غالبا ما تُعطى هذه الأرقام والسلاسل المحددة أسماءً مفهومة عن طريق الثوابت، وهو السبب في استخدام هذه الرموز بشكل كبير. المشكلة يحتوي الصنف على حقل يحتوي على رموز الأنواع. ولا تُستخدم قيم هذا النوع في شروط المُشغِّل ولا تؤثر على سلوك البرنامج. الحل إنشاء صنف جديد واستخدام كائناته بدلًا ...

توصيف المشكلة وجود ما يزيد عن ثلاثة أو أربعة معاملات (parameters) مُمرَّرة للتابع (method). أسبابها قد تحدث هذه المشكلة عند دمج عدّة خوارزمياتٍ بنفس التابع (method)، إذ تُستخدَم المعاملات (parameters) الكثيرة لتحديد الخوارزمية التي ستُنفَّذ وآليّتها. أو قد تنتج المشكلة عن محاولة المبرمج أو المطوِّر لجعل الأصناف (classes) أكثر استقلاليةً عن بعضها البعض. فمثلًا: عند نقل الشيفرة التي تنشِئ الكائنات (objects) -اللازمة لأحد التوابع- من داخل التابع إلى الشيفرة التي تستدعي ذلك التابع سيتطلَّبُ تمرير تلك الكائنات إلى التابع كمعاملاتٍ ...

المشكلة تخزين نتيجة تعبيرٍ ما (expression) في متغيِّر محليٍّ (local variable) لاستخدامه لاحقًا في الشيفرة. الحل نقل التعبير بأكمله إلى تابعٍ (method) مستقلٍ يعيد نتيجته، وعندها سيكون استدعاء هذا التابع بديلًا عن استخدام المتغيِّر (variable)، ومن الممكن أيضًا دمج هذا التابع مع توابع أخرى عند الحاجة للقيام بذلك. مثال قبل إعادة التصميم نلاحظ في الشيفرة الآتية وجود متغيِّرٍ مؤقتٍ باسم basePrice لتخزين القيمة الناتجة عن تنفيذ التعبير الرياضيّ بمعامل الجداء (أي المعامل *)، وسيُستخدَم هذا المتغيِّر لاحقًا في الأجزاء الشرطيّة ...

المشكلة وجود صنفين لهما حقول وتوابع مشتركة. الحل إنشاء صنف أب مشترك لهما ونقل جميع الحقول والتوابع المتطابقة إليه. مثال قبل إعادة التصميم يملك الصنفين Department و Employee توابعًا مشتركة فيما بينهما: وجود صنفين لهما حقول وتوابع مشتركة. بعد إعادة التصميم إنشاء صنف أب لهما يدعى Party يحوي التوابع المشتركة: إنشاء صنف فائق مشترك لهما ونقل جميع الحقول والتوابع المتطابقة إليه. لم إعادة التصميم؟ يحدث نوع من تكرار الشيفرة عندما يؤدي صنفان نفس المهام بنفس الطريقة أو بطرق مختلفة. وتتيح ...

المشكلة ينقسم التابع إلى أجزاء، كل منها يتم تشغيله اعتمادًا على قيمة المعامل. الحل استخراج الأجزاء الفردية من التابع إلى توابعها الخاصة واستدعائها بدلًا من استدعاء التابع الأصلي. مثال قبل إعادة التصميم وجود تابع يدعى ()setValue يضبط قيمة الارتفاع والعرض بناءً على تمرير سلسلة نصية صريحة بذلك: في لغة Java: void setValue(String name, int value) { if (name.equals("height")) { height = value; return; } if (name.equals("width")) { width ...

ملاحظة قبل البدء إنّ مشكلة التغيير المتشعِّب هي المشكلة المعاكسة تمامًا لمشكلة تغيير الأصناف المتعدِّدة (Shotgun Surgery)، إذ إنّ التغيير المتشعِّب هو مجموع التغييرات الكثيرة التي تُجرَى في صنفٍ (class) واحدٍ، أما تغيير الأصناف المتعدِّدة فهو تغييرٌ واحدٌ يُجرَى في العديد من الأصناف. توصيف المشكلة الحاجة لتغيير الكثير من التوابع التي لا علاقة لها بالأمر بمجرَّد إحداث أيّ تغيير في الصنف (class)، فمثلًا؛ لدى إضافة منتجٍ جديدٍ عليك تعديل التوابع المسؤولة عن البحث عن المنتجات وعرضها وتنظيمها، وهذا مستهلكٌ للوقت ...

المشكلة يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر. الحل جعل الصنف مفوِّض وارث، الأمر الذي يجعل تابع التفويض غير ضروري. مثال قبل إعادة التصميم التابع الموجود في الصنف Employee مفوَّض إلى التابع ()getName في الصنف Person: يحتوي الصنف على العديد من التوابع البسيطة التي تفوِّض إلى كل التوابع في صنفٍ آخر. بعد إعادة التصميم جعل الصنف Employee يرث من الصنف Person والتخلص من التفويض: أصبح الصنف مفوِّض وارث، الأمر الذي يجعل تابع ...

ملاحظة قبل البدء: تختلف هذه التقنية عن تقنية تغليف الحقول (Encapsulate Field) من حيث أنّها تُستخدَم لتغليف الحقول الخاصّة (أي المُحدَّدة بالكلمة المفتاحيّة private). المشكلة الوصول المباشر إلى الحقول الخاصّة (private fields) داخل الصنف (class). الحل إنشاء تابعي الوصول getter و setter للحقل الخاصّ ومنع الوصول إليه إلا عبرهما. مثال قبل إعادة التصميم يحتوي الصنف Range على الحقلين low و high من النوع الخاص (private) ونلاحظ الوصول إليهما مباشرةً داخل التابع includes في الشيفرة الآتية: في لغة Java: class Range ...

المشكلة وجود العديد من النُسَخ المتماثلة من صنفٍ واحدٍ تحتاج إلى استبدال كائنٍ واحدٍ بها. الحل تحويل الكائنات المتماثلة إلى كائن مرجعي واحد. مثال قبل إعادة التصميم مخطط يوضح وجود العديد من النُسَخ المتماثلة من الصنف Order: مخطط يوضح وجود العديد من النُسَخ المتماثلة من صنفٍ Order. بعد إعادة التصميم تحويل الكائنات المتماثلة إلى كائن مرجعي واحد: تحويل الكائنات المتماثلة إلى كائن مرجعي واحد. لم إعادة التصميم؟ في العديد من الأنظمة، يمكن تصنيف الكائنات على أنها إمَّا قيم أو مراجع. ...

المشكلة لكي يعمل جزء من الشيفرة البرمجية بشكل صحيح، يجب أن تتحقق بعض الشروط أو تكون القيم صحيحة. الحل استبدل هذه الافتراضات بنقاط تحقق خاصة بالتوكيد. مثال قبل إعادة التصميم تعريف دالة تعيد قيمة عددية - ثمتِّل حد النفقات - مع افتراض تحقق أحد أمرين دون التأكد من هما: في لغة Java: double getExpenseLimit() { // يجب أن يكون إما حدًا للنفقات أو مشروعًا أساسيًا return (expenseLimit != NULL_EXPENSE) ? expenseLimit: primaryProject.getMemberExpenseLimit(); } في ...

المشكلة وجود مجموعة متداخلة من الشروط وصعوبة تحديد التدفق الطبيعي لتنفيذ الشيفرة البرمجية. الحل عزل جميع الاختبارات الخاصة والحالات الطرفية في عبارات منفصلة ووضعها قبل الاختبارات الرئيسية. من الناحية المثالية، يجب أن يكون لديك قائمة "مسطحة" من الشروط، واحدةً تلو الأخرى. مثال قبل إعادة التصميم يوجد لدينا الدالة ()getPayAmount التي تتحقق من القيمة المُستدعاة معها عبر عدد من الشروط المتشعبة - مع استعمال المتغير result للحصول على النتيجة وإعادتها في النهاية - مما يجعل معرفة تدفق ومسار الدالة أمرًا معقدًا: ...

توصيف المشكلة وجود تركيبٍ معقَّدٍ لتعليمة switch أو عدّة تعليمات if متسلسلة. أسبابها ما يميِّز البرمجة كائنيّة التوجّه (OO) هو اعتمادها النادر على المعاملين switch و case، إذ تُوزَّع شيفرة switch بمواقع مختلفة من البرنامج بدلًا من تجمعيها في تعليمة switch واحدةٍ، وعند إضافة شرطٍ جديدٍ عليك إيجاد كافّة شيفرات switch لتعديلها، وكقاعدة عامّة: وجود تعليمة switch يعني أن عليك البدء بالتفكير بمبدأ التعدديّة الشكليّة (polymorphism). وما الحل؟ عزل تعليمة switch ووضعها بالصنف الصحيح عبر إنشاء صنفٍ (class) ونقل التابع ...

تقنية إعادة التصميم هذه هي حالة خاصة من تبديل قيم البيانات إلى كائنات. المشكلة لديك مصفوفة تحتوي على أنواع مختلفة من البيانات. الحل استبدال المصفوفة بكائن يكون له حقول منفصلة لكل عنصر. مثال قبل إعادة التصميم احتواء المصفوفة row على نوعين مختلفين من البيانات (سلسلة نصية وعدد): في لغة Java: String[] row = new String[2]; row[0] = "Liverpool"; row[1] = "15"; في لغة C#‎: string[] row = new string[2]; row[0] = "Liverpool"; row[1] = "15"; في لغة PHP: $row = array(); $row[0] = "Liverpool"; $row[1] = 15; في لغة ...

المشكلة تحتوي التوابع على نفس المجموعة المتكررة من المعاملات. الحل استبدال هذه المعاملات بكائنٍ واحد. مثال قبل إعادة التصميم تمرير نفس مجموعة المعاملات إلى توابع الصنف Customer: تحتوي التوابع على نفس المجموعة المتكررة من المعاملات. بعد إعادة التصميم تبديل كائن واحد بتلك المعاملات وتمريره إلى توابع الصنف Customer التي تشترك بنفس مجموعة المعاملات: استبدال هذه المعاملات بكائنٍ واحد. لم إعادة التصميم؟ غالبًا ما تُصادَف مجموعات متطابقة من المعاملات داخل العديد من التوابع. الأمر الذي يؤدي إلى تكرار الشيفرة البرمجية للمعاملات ...

المشكلة إطلاق استثناء يمكن لاختبار بسيط أن يحل محله. الحل يستعاض عن الاستثناء باختبار الحالة. مثال قبل إعادة التصميم معالجة الاستثناء الحاصل عند وقوع الفهرس periodNumber خارج حدود مصفوفة القيم values وإعادة القيمة 0 آنذاك: في لغة Java: double getValueForPeriod(int periodNumber) { try { return values[periodNumber]; } catch (ArrayIndexOutOfBoundsException e) { return 0; } } في لغة C#‎: double GetValueForPeriod(int periodNumber) { try { return values[periodNumber]; ...