المهايئ (Adapter).

المهايئ (Adapter) هو نمط تصميم هيكلي يسمح للكائنات ذات الواجهات غير المتوافقة بالتعاون معاً.

تخيل أنك تقوم بإنشاء تطبيق لمراقبة سوق الأسهم. يقوم التطبيق بتنزيل بيانات الأسهم من مصادر متعددة بتنسيق XML ثم يعرض مخططات ورسومات بيانية جذابة للمستخدم.

في مرحلة ما، تقرر تحسين التطبيق من خلال دمج مكتبة تحليلات ذكية تابعة لجهة خارجية. ولكن هناك مشكلة: مكتبة التحليلات تعمل فقط مع البيانات بتنسيق JSON.

يمكنك تغيير المكتبة لتعمل مع XML. ومع ذلك، قد يؤدي هذا إلى كسر بعض الأكواد الحالية التي تعتمد على المكتبة. والأسوأ من ذلك، قد لا تتمكن من الوصول إلى الكود المصدري للمكتبة في المقام الأول، مما يجعل هذا النهص مستحيلاً.

يمكنك إنشاء مهايئ. هذا كائن خاص يقوم بتحويل واجهة كائن ما بحيث يمكن لكائن آخر فهمها.

يلف المهايئ أحد الكائنات لإخفاء تعقيد التحويل الذي يحدث خلف الكواليس. الكائن الملفوف لا يدرك حتى وجود المهايئ. على سبيل المثال، يمكنك تغليف كائن يعمل بالأمتار والكيلومترات بمهايئ يحول جميع البيانات إلى وحدات إمبراطورية مثل القدم والميل.

لا يمكن للمهايئات تحويل البيانات إلى تنسيقات مختلفة فحسب، بل يمكنها أيضاً مساعدة الكائنات ذات الواجهات المختلفة على التعاون. وإليك كيف يعمل:

1. يحصل المهايئ على واجهة متوافقة مع أحد الكائنات الحالية.
2. باستخدام هذه الواجهة، يمكن للكائن الحالي استدعاء دوال المهايئ بأمان.
3. عند تلقي استدعاء، يمرر المهايئ الطلب إلى الكائن الثاني، ولكن بالتنسيق والترتيب الذي يتوقعه الكائن الثاني.

في بعض الأحيان يكون من الممكن إنشاء مهايئ ثنائي الاتجاه يمكنه تحويل الاستدعاءات في كلا الاتجاهين.

دعنا نعود إلى تطبيق سوق الأسهم الخاص بنا. لحل معضلة التنسيقات غير المتوافقة، يمكنك إنشاء مهايئات XML-to-JSON لكل فئة من مكتبة التحليلات التي يعمل كودك معها مباشرة. ثم تقوم بضبط كودك للتواصل مع المكتبة فقط عبر هذه المهايئات. عندما يتلقى المهايئ استدعاءً، فإنه يترجم بيانات XML الواردة إلى بنية JSON ويمرر الاستدعاء إلى الدوال المناسبة لكائن التحليلات الملفوف.

يعتمد هذا المثال لنمط **المهايئ (Adapter)** على الصراع الكلاسيكي بين الأوتاد المربعة والثقوب المستديرة.

يتظاهر المهايئ بأنه وتد مستدير، بنصف قطر يساوي نصف قطر قطر المربع (بمعنى آخر، نصف قطر أصغر دائرة يمكن أن تستوعب الوتد المربع).

// لنفترض أن لديك فئتين بواجهات متوافقة:
// RoundHole و RoundPeg.
class RoundHole is
    constructor RoundHole(radius) { ... }

    method getRadius() is
        // إرجاع نصف قطر الثقب.

    method fits(peg: RoundPeg) is
        return this.getRadius() >= peg.getRadius()

class RoundPeg is
    constructor RoundPeg(radius) { ... }

    method getRadius() is
        // إرجاع نصف قطر الوتد.


// ولكن هناك فئة غير متوافقة: SquarePeg.
class SquarePeg is
    constructor SquarePeg(width) { ... }

    method getWidth() is
        // إرجاع عرض الوتد المربع.


// تتيح لك فئة المهايئ ملاءمة الأوتاد المربعة في الثقوب المستديرة.
// وهي توسع فئة RoundPeg لتمكين كائنات المهايئ من العمل كأوتاد مستديرة.
class SquarePegAdapter extends RoundPeg is
    // في الواقع، يحتوي المهايئ على نسخة من فئة SquarePeg.
    private field peg: SquarePeg

    constructor SquarePegAdapter(peg: SquarePeg) is
        this.peg = peg

    method getRadius() is
        // يتظاهر المهايئ بأنه وتد مستدير بنصف قطر يمكنه
        // استيعاب الوتد المربع الذي يلفه المهايئ بالفعل.
        return peg.getWidth() * Math.sqrt(2) / 2


// في مكان ما في كود العميل.
hole = new RoundHole(5)
rpeg = new RoundPeg(5)
hole.fits(rpeg) // true

small_sqpeg = new SquarePeg(5)
large_sqpeg = new SquarePeg(10)
hole.fits(small_sqpeg) // لن يتم تجميع هذا (أنواع غير متوافقة)

small_sqpeg_adapter = new SquarePegAdapter(small_sqpeg)
large_sqpeg_adapter = new SquarePegAdapter(large_sqpeg)
hole.fits(small_sqpeg_adapter) // true
hole.fits(large_sqpeg_adapter) // false

1. تأكد من أن لديك فئتين على الأقل بواجهات غير متوافقة:

   • فئة خدمة مفيدة لا يمكنك تغييرها (غالباً ما تكون تابعة لجهة خارجية، أو كود قديم، أو تحتوي على الكثير من الاعتماديات الحالية).
   • فئة عميل واحدة أو أكثر ستستفيد من استخدام فئة الخدمة.

2. أعلن عن واجهة العميل ووصف كيف يتواصل العملاء مع الخدمة.

3. أنشئ فئة المهايئ واجعلها تتبع واجهة العميل. اترك جميع الدوال فارغة في الوقت الحالي.

4. أضف حقلاً إلى فئة المهايئ لتخزين مرجع لكائن الخدمة. الممارسة الشائعة هي تهيئة هذا الحقل عبر المنشئ (constructor)، ولكن في بعض الأحيان يكون من الأنسب تمريره إلى المهايئ عند استدعاء دواله.

5. واحدة تلو الأخرى، قم بتنفيذ جميع دوال واجهة العميل في فئة المهايئ. يجب على المهايئ تفويض معظم العمل الفعلي لكائن الخدمة، مع معالجة الواجهة أو تحويل تنسيق البيانات فقط.

6. يجب على العملاء استخدام المهايئ عبر واجهة العميل. سيتيح لك ذلك تغيير المهايئات أو توسيعها دون التأثير على كود العميل.

• يتم تصميم الجسر (Bridge) عادةً بشكل مسبق، مما يتيح لك تطوير أجزاء من التطبيق بشكل مستقل عن بعضها البعض. من ناحية أخرى، يُسخدم المهايئ (Adapter) بشكل شائع مع تطبيق موجود لجعل بعض الفئات غير المتوافقة تعمل معاً بشكل جيد.

• يوفر المهايئ (Adapter) واجهة مختلفة تماماً للوصول إلى كائن موجود. من ناحية أخرى، مع نمط المزخرف (Decorator) تظل الواجهة كما هي أو يتم توسيعها. بالإضافة إلى ذلك، يدعم المزخرف التركيب العودي، وهو أمر غير ممكن عند استخدام المهايئ.

• باستخدام المهايئ (Adapter) يمكنك الوصول إلى كائن موجود عبر واجهة مختلفة. باستخدام الوكيل (Proxy)، تظل الواجهة كما هي. باستخدام المزخرف (Decorator) يمكنك الوصول إلى الكائن عبر واجهة محسنة.

• الواجهة (Facade) يعرّف واجهة جديدة للكائنات الموجودة، بينما يحاول المهايئ (Adapter) جعل الواجهة الحالية قابلة للاستخدام. يلف _المهايئ_ عادةً كائناً واحداً فقط، بينما يعمل _الواجهة_ مع نظام فرعي كامل من الكائنات.

• تمتلك أنماط الجسر (Bridge)، الحالة (State)، الاستراتيجية (Strategy) (وإلى حد ما المهايئ (Adapter)) هياكل متشابهة جداً. في الواقع، تعتمد جميع هذه الأنماط على التركيب (composition)، وهو تفويض العمل لكائنات أخرى. ومع ذلك، فإنها جميعاً تحل مشكلات مختلفة. النمط ليس مجرد وصفة لهيكلة الكود الخاص بك بطريقة معينة. يمكنه أيضاً إبلاغ المطورين الآخرين بالمشكلة التي يحلها النمط.