نتائج البحث

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

المشكلة تؤدي توابع متعددة أعمالًا مماثلة تختلف فقط من حيث قيمها الداخلية أو أرقامها أو عملياتها. الحل تجميع هذه التوابع باستخدام معامل يُمرر القيمة الخاصة الضرورية. مثال قبل إعادة التصميم يؤدي التابعان ()fivePercentRaise و ()tenPercentRaise الغرض ذاته باختلاف النسبة المئوية المراد زيادتها للموظف Employee: يؤدي التابعان أعمالًا مماثلة تختلف فقط من حيث قيمها الداخلية أو أرقامها أو عملياتها. بعد إعادة التصميم تجميع التابعان السابقان في تابع واحد يدعى ()raise مع تمرير النسبة المئوية المتغيرة إليه: يجمع التابعين باستخدام معامل يُمرر ...

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

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

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

يتم إنشاء كائنات الصنف Method بواسطة التابع Object.method، وترتبط بكائن معين (وليس بالصنف وحسب). ويمكن استخدامها لاستدعاء التابع داخل الكائن، أو ككتلة (block) مرتبطة بمكرر (iterator). كما يمكن فك ارتباطها (unbound) من كائن محدد (سيؤدي ذلك إلى إنشاء الكائن UnboundMethod) ثم ربطها بآخر. class Thing def square(n) n*n end end thing = Thing.new meth = thing.method(:square) meth.call(9) #=> 81 [ 1, 2, 3 ...

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

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

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

المشكلة تحتوي الأصناف الفرعية على توابع تؤدي نفس العمل. الحل جعل التوابع متطابقة ثم نقلها إلى الصنف الأعلى ذي الصلة. مثال قبل إعادة التصميم يحتوي الصنفان الفرعيان Soldier و Tank على التابع ()getHealth الذي يؤدي نفس العمل: تحتوي الأصناف الفرعية على التابع ()getHealth تؤدي نفس العمل. بعد إعادة التصميم نقل التابع ()getHealth إلى الصنف Unit الأب وإزالته من الأصناف الفرعية: نقل التابع ()getHealth إلى الصنف الأعلى. لم إعادة التصميم؟ تنمو الأصناف الفرعية وتتطور بشكل مستقل عن بعضها البعض، مما يتسبب ...