عرض مصدر Refactoring/inline class

<noinclude>{{DISPLAYTITLE:دمج الصنف (Inline Class)}}</noinclude>
== المشكلة ==
وجود صنفٍ (class) لا يقوم بأيّ مهمّة فعليّة ولا يُخطَّط لإضافة مهامٍ إليه لاحقًا.

== الحل ==
نقل كافّة الميّزات (features) من هذا الصنف إلى صنفٍ آخر.

=== مثال ===

==== قبل إعادة التصميم ====
يحتوي الصنف <code>Person</code> على حقلٍ واحدٍ باسم <code>name</code> وتابعٍٍ للحصول على رقم الهاتف <code>getTelephoneNumber</code> ولاشيء آخر، أمّا الصنف <code>TelephoneNumber</code> فهو يحتوي على حقلين باسم <code>officeAreaCode</code> و <code>officeNumber</code> بالإضافة إلى التابع السابق <code>getTelephoneNumber</code>، كما هو موضَّحٌ في مخطط الأصناف الآتي:
[[ملف:Inline-Class-Before.png|بديل=الصنف Person يحتوي على حقلٍ واحدٍ باسم name وتابعٍٍ للحصول على رقم الهاتف getTelephoneNumber، أمّا الصنف TelephoneNumber فهو يحتوي على حقلين باسم officeAreaCode و officeNumber بالإضافة إلى التابع السابق getTelephoneNumber.|بدون|الصنف Person يحتوي على حقلٍ واحدٍ باسم name وتابعٍٍ للحصول على رقم الهاتف getTelephoneNumber، أمّا الصنف TelephoneNumber فهو يحتوي على حقلين باسم officeAreaCode و officeNumber بالإضافة إلى التابع السابق getTelephoneNumber.|500x500px|تصغير]]
==== بعد إعادة التصميم ====
دُمِج الصنف <code>TelephoneNumber</code> مع الصنف <code>Person</code> ليشمل كلَّ الحقول والتوابع الموجودة فيهما، كما في مخطط الأصناف الآتي:
[[ملف:Inline-Class-After.png|بديل=الصنف Person يحتوي على عددٍ من الحقول كاسم الشخص (name) ورمز منطقة المكتب (officeAreaCode) ورقمه (officeNumber)، وتابعًا للحصول على هذا الرقم باسم getTelephoneNumber.|بدون|الصنف Person يحتوي على عددٍ من الحقول كاسم الشخص (name) ورمز منطقة المكتب (officeAreaCode) ورقمه (officeNumber)، وتابعًا للحصول على هذا الرقم باسم getTelephoneNumber.|280x280px|تصغير]]

== لم إعادة التصميم؟ ==
يُلجَأ عادةً إلى دمج الصنف من بعد نقل ميّزاته (features) إلى أصناف أخرى بحيث يصبح الصنف مهملًا ولا أهمية لما يقوم به.

== فوائد تطبيق الحل ==
التقليل من الأصناف غير الضروريّة في البرنامج مما يعني استفادةً أكبر من الذاكرة أثناء التشغيل، وكذلك من دماغ المبرمج! فلِمَ يشغل تفكيره بأصنافٍ لا أهمية لها؟

== آلية الحل ==
# إنشاء حقولٍ وتوابع عامّةٍ (public fields/methods) في الصنف المستقبِل (recipient class) بما يتناسب مع الحقول والتوابع الموجودة في الصنف الأصليّ الذي سيُدمج.
# تبديل كل مرجعيّات (references) الصنف الأصليّ إلى مرجعيّات الحقول والتوابع الجديدة في الصنف المستقبِل.
# اختبار البرنامج والتأكُّد من عدم حدوث أيّ أخطاءٍ بالنتائج، وبمجرد اجتياز الاختبار بنجاح يجب البدء بتطبيق تقنيتي [[Refactoring/move method|نقل التوابع]] (Move Methods) و<nowiki/>[[Refactoring/move field|نقل الحقول]] (Move Fields) لنقل المهام (functionality) بأكملها من الصنف الأصليّ إلى الصنف المستقبل، والاستمرار بنقلها إلى أن يصبح الصنف فارغًا بأكمله.
# حذف الصنف الأصليّ.

== انظر أيضًا ==
* [[Refactoring/extract class|استخراج الصنف]].
* [[Refactoring/inline method|دمج التوابع]].
* [[Refactoring/inline temp|دمج المتغيِّر المؤقّت]].

== مصادر ==
* [https://refactoring.guru/inline-class صفحة توثيق دمج الصنف في موقع refactoring.guru.]
[[تصنيف:Refactoring]]
[[تصنيف:Refactoring Techniques]]
[[تصنيف:Refactoring Moving Features between Objects]]