تنظيم البيانات (Organizing Data)
< Refactoring | techniques
تساعد تقنيات إعادة التصميم هذه بالتعامل مع البيانات، وتبديل أصناف ذات وظائف كثيرة مكان الأنواع الأساسية (primitives). نتيجة أخرى مهمة نحصل عليها بتطبيق هذه التقنيات هي فك ارتباطات صنف مما يجعل الصنف قابلًا للنقل وإعادة الاستعمال. وهذه التقنيات هي:
- التغليف الداخلي للحقول (Self Encapsulate Fields)
- المشكلة: الوصول المباشر إلى الحقول الخاصّة داخل الصنف.
- الحل: إنشاء تابعي الجلب (getter) والضبط (setter) للحقل الخاصّ ومنع الوصول إليه إلا عبرهما.
- تبديل قيم البيانات إلى كائنات (Replace Data Values with Objects)
- المشكلة: وجود حقلٍ مٌخصَّص للبيانات في صنفٍ ما (أو في عددٍ من الأصناف)، ولهذا الحقل بياناته وسلوكه المرتبط به.
- الحل: إنشاء صنفٍ جديدٍ ليُوضَع فيه الحقل بالإضافة إلى سلوكه المرتبط به، وتخزين كائنٍ من هذا الصنف الجديد في الصنف الأصليّ للحقل.
- تبديل القيمة إلى مرجع (Change Value to Reference)
- المشكلة: وجود العديد من النُسَخ المتماثلة من صنفٍ واحدٍ تحتاج إلى استبدال كائنٍ واحدٍ بها.
- الحل: تحويل الكائنات المتماثلة إلى كائن مرجعي واحد.
- تبديل المرجع إلى قيمة (Change Reference to Value)
- المشكلة: وجود كائن مرجع صغير جدًا نادرًا ما يتغيَّر لتبرير إدارة دورة حياته.
- الحل: تحويله إلى كائن قيمة (value object).
- تبديل المصفوفات بكائنات (Replace Array with Object)
- المشكلة: لديك مصفوفة تحتوي على أنواع مختلفة من البيانات.
- الحل: استبدال المصفوفة بكائن يكون له حقول منفصلة لكل عنصر.
- تكرار البيانات المرُاقَبة (Duplicate Observed Data)
- المشكلة: هل بيانات النطاق المخزَّنة في أصناف هي المسؤولة عن واجهة المستخدم الرسومية (GUI)؟ إذًا، إليك الحل.
- الحل: فصل البيانات في أصناف منفصلة لضمان الاتصال والتزامن بين صنف النطاق وواجهة المستخدم الرسومية (GUI).
- تغيير الاقتران أحادي الاتجاه إلى ثنائي الاتجاه (Change Unidirectional Association to Bidirectional)
- المشكلة: وجود صنفان يحتاج كل منهما إلى استخدام ميزات الآخر، ولكن الاقتران بينهما أحادي الاتجاه فقط.
- الحل: إضافة الاقتران المفقود إلى الصنف الذي يحتاج إليه.
- تغيير الاقتران ثنائي الاتجاه إلى أحادي الاتجاه (Change Bidirectional Association to Unidirectional)
- المشكلة: وجود اقتران ثنائي الاتجاه (bidirectional association) بين الأصناف، ولكن لا يستخدم أحد الأصناف الميزات الأخرى.
- الحل: إزالة الاقتران غير المستخدم.
- تبديل الأعداد السحرية بثوابت رمزية (Replace Magic Number with Symbolic Constant)
- المشكلة: تستخدم الشيفرة البرمجية عددًا له معنىً معين له.
- الحل: استبدال هذا العدد بثابت له اسم يمكن قراءته ويشرح معنى العدد.
- تغليف الحقول (Encapsulate Field)
- المشكلة: لديك حقل عام.
- الحل: جعل الحقل خاصًّا وإنشاء توابع وصول له.
- تغليف المجموعات (Encapsulate Collection)
- المشكلة: صنف يحتوي على حقل مجموعة وجالب (getter) وضابط (setter) بسيط للعمل مع المجموعة.
- الحل: ضبط القيمة المعادة من المُتلقي لتكون للقراءة فقط وإنشاء توابع لإضافة/حذف عناصر المجموعة.
- تبديل رموز الأنواع بالأصناف (Replace Type Code with Class)
- المشكلة: يحتوي الصنف على حقل يحتوي على رموز الأنواع. ولا تُستخدم قيم هذا النوع في شروط المُشغِّل ولا تؤثر على سلوك البرنامج.
- الحل: إنشاء صنف جديد واستخدام كائناته بدلًا من قيم رموز الأنواع.
- تبديل رموز الأنواع بالأصناف الفرعية (Replace Type Code with Subclasses)
- المشكلة: يؤثر النوع المُرمَّز على سلوك البرنامج (تُطلِق قيم هذا الحقل رموز مختلفة في الشرطيات).
- الحل: إنشاء أصناف فرعية لكل قيمة من النوع المُرمَّز. ثم استخراج السلوكيات ذات الصلة من الصنف الأصلي إلى هذه الأصناف الفرعية. وتبديل رموز التحكم في التدفق بالتعدديّة الشكليّة (polymorphism).
- تبديل رموز الأنواع بالحالة/الاستراتيجية (Replace Type Code with State/Strategy)
- المشكلة: يؤثر نوع مُرمَّز على سلوك البرنامج ولكن لا يمكن استخدام الأصناف الفرعية للتخلص منه.
- الحل: استبدال رمز النوع بكائن حالة. إذا كان من الضروري استبدال قيمة حقل برمز النوع، فسيكون كائن حالة آخر "موصولًا" ("plugged-in").
- استبدال الأصناف الفرعية بالحقول (Replace Subclass with Fields)
- المشكلة: لديك أصناف فرعية تختلف فقط في توابع (إعادة الثوابت) الخاصة بها.
- الحل: استبدال التوابع بالحقول في الصنف الأب وحذف الأصناف الفرعية.