الفرق بين المراجعتين لصفحة: «Refactoring/primitive obsession»
أنشأ الصفحة ب'<noinclude>{{DISPLAYTITLE:هوس الحقول الأساسية (Primitive Obsession)}}</noinclude> == توصيف المشكلة == تظهر المشكلة بعدَّة...' |
جميل-بيلوني (نقاش | مساهمات) ط تعديل التصنيفات |
||
سطر 33: | سطر 33: | ||
[[تصنيف:Refactoring]] | [[تصنيف:Refactoring]] | ||
[[تصنيف:Refactoring Smells]] | [[تصنيف:Refactoring Smells]] | ||
[[تصنيف:Refactoring | [[تصنيف:Refactoring Bloaters]] |
المراجعة الحالية بتاريخ 07:29، 2 مارس 2019
توصيف المشكلة
تظهر المشكلة بعدَّة جوانب:
- استخدام الحقول الأساسيّة (primitives) بدلًا من الكائنات (objects) لأداء المهامّ البسيطة (مثل: عمليات العملة [currency] والمجالات [ranges] والسلاسل النصية [strings] المُخصَّصة للأرقام الهاتفية، …إلخ.).
- استخدام الثوابت (constants) لترميز المعلومات (مثل استخدام الثابت
USER_ADMIN_ROLE = 1
للدلالة على المستخدمين ذوي الصلاحيّات الإداريّة). - استخدام الثوابت النصيّة (string constants) كأسماءٍ للحقول (fields) في مصفوفات البيانات (data arrays).
أسبابها
تنشأ هذه المشكلة بسبب العبارة المُدمِّرة التي يفكّر بها المبرمجون بلحظة ضعفٍ:
"حقلٌ واحدٌ فقط، ولتخزين معلومةٍ بسيطةٍ وحسب!"
ولأنهم يرون من السهل إضافةُ حقلٍ أساسيِّ جديدٍ بدلًا من إنشاء صنفٍ جديدٍ كليًّا؛ حقلٌ يُضاف هنا، وآخر ضروريٌّ أيضًا هناك، وثالثٌ ورابعٌ إلى أن يصبح الصنف ضخمًا يصعُب التعامل معه، لنضع بالحسبان أنّ الهدف من استخدام الحقول الأساسيّة (primitives) هو محاكاتها للأنواع (type simulation)، أي تُستخدَمُ مجموعةٌ من الأرقام أوالسلاسل النصيّة (بدلًا من نوعٍ منفصلٍ للبيانات) لتحديد القائمة التي يُسمَح بها من القيم لكيانٍ ما، وتُعطى -فيما بعد- أسماءً مُعبِّرةً يسيرة الفهم عبر الثوابت (constants)، وهذا ما يُفسِّر انتشارها وتعدُّد استخداماتها.
وكمثالٍ آخر عن الاستخدام غير المجدي؛ قد تُستخدَم بهدف محاكاة الحقول (field simulation)، وذلك عندما يحتوي الصنف مصفوفةً ضخمةً بالكثير من البيانات المتنوعة والثوابت النصيّة (التي تُحدَّد في الصنف) وتستخدم كفهارس (indices) للوصول إلى بيانات المصفوفة.
وما الحل؟
بإمكانك تجربة الحلول الآتية:
- تجميع الحقول المتقاربة في صنفٍ (class) خاصٍ بها، وحبَّذا نقلُ السلوك (behaviour) المتعلِّق بهذه الحقول إلى الصنف الجديد أيضًا (راجع تبديل قيم البيانات إلى كائنات [objects]).
- إن كانت تلك الحقول مستخدمةً في إحدى قوائم معاملات التوابع (method parameters) فالحل يكمُن بإنشاء كائن المعاملات (parameter object) أو التعامل مع الكائن ككُل (whole object).
- عند تشفير البيانات المُعقَّدة بواسطة المتغيِّرات (variables) فالحل الأمثل هو تبديل شيفرة النوع (type code) إلى صنف (class) أو تبديل شيفرة النوع إلى صنف فرعيّ (subclass) أو تبديل شيفرة النوع إلى حالة/استراتيجيّة (state/strategy).
- لدى وجود مصفوفات (arrays) بين المتغيِّرات (variables) فعليك بتبديل المصفوفة إلى كائن (object).
إليك المزيد
تصبح الشيفرة أكثر مرونةً بفضل استخدام الكائنات (objects) بدلًا من الحقول الأساسيّة (primitives)، كما وستحصل على تنظيمٍ أفضل للشيفرة ممّا يُسهِّل فهمها؛ إذ تصبح كل العمليات (operations) المتعلِّقة ببيانات مُعيَّنة مُجمَّعةً بمكانٍ واحدٍ بدلًا من كونها متفرِّقة، ولن يكون هناك أيُّ داعٍ للتساؤل عن سبب انتشار الثوابت هنا وهناك، أضف لذلك أنّه سيصبح من السهل كشف الشيفرات المُكرَّرة (duplicate code) في البرنامج.
انظر أيضًا
- تبديل قيم البيانات إلى كائنات (objects)
- تبديل المصفوفات إلى كائنات
- كائن المعاملات (parameter object)
- تبديل شيفرة النوع (type code) إلى صنف (class)
- تبديل شيفرة النوع إلى صنف فرعيّ (subclass)
- تبديل شيفرة النوع إلى حالة/استراتيجيّة (state/strategy)