الجسر.

الجسر هو نمط تصميم هيكلي يتيح لك تقسيم كلاس ضخم أو مجموعة من الكلاسات المترابطة إلى تسلسلين هرميين منفصلين — التجريد والتنفيذ — يمكن تطويرهما بشكل مستقل عن بعضهما.

التجريد؟ التنفيذ؟ يبدو الأمر مخيفاً؟ لا تقلق، دعنا نتأمل مثالاً بسيطاً.

لنفترض أن لديك كلاساً هندسياً Shape مع زوج من الكلاسات الفرعية: Circle وSquare. تريد توسيع هذا التسلسل الهرمي ليشمل الألوان، لذا تخطط لإنشاء كلاسات فرعية Red وBlue. غير أنك بما أن لديك كلاسين فرعيين بالفعل، ستحتاج إلى إنشاء أربع تركيبات مثل BlueCircle وRedSquare.

إضافة أنواع جديدة من الأشكال والألوان إلى التسلسل الهرمي ستُنمِّيه بشكل أسي. على سبيل المثال، لإضافة شكل مثلث ستحتاج إلى إدخال كلاسين فرعيين، أحدهما لكل لون. وبعد ذلك، إضافة لون جديد ستستلزم إنشاء ثلاثة كلاسات فرعية، واحد لكل نوع من الأشكال. كلما تقدمنا، كلما ساءت الأمور.

تنشأ هذه المشكلة لأننا نحاول توسيع كلاسات الأشكال في بُعدين مستقلين: حسب الشكل وحسب اللون. وهذه مشكلة شائعة جداً في الوراثة الكلاسية.

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

باتباع هذا النهج، يمكننا استخراج الكود المتعلق بالألوان في كلاسه الخاص مع كلاسين فرعيين: Red وBlue. يحصل كلاس Shape بعد ذلك على حقل مرجع يشير إلى أحد كائنات الألوان. يمكن للشكل الآن تفويض أي عمل متعلق بالألوان إلى كائن اللون المرتبط به. سيعمل ذلك المرجع كجسر بين كلاسَي Shape وColor. من الآن فصاعداً، إضافة ألوان جديدة لن تستلزم تغيير التسلسل الهرمي للأشكال، والعكس صحيح.

التجريد والتنفيذ

يُقدِّم كتاب GoF "عصابة الأربعة" هو لقب يُطلق على المؤلفين الأربعة للكتاب الأصلي عن أنماط التصميم: Design Patterns: Elements of Reusable Object-Oriented Software https://refactoring.guru/gof-book. مصطلحَي التجريد والتنفيذ كجزء من تعريف نمط الجسر. في رأيي، يبدو هذان المصطلحان أكاديميَّين للغاية ويجعلان النمط يبدو أكثر تعقيداً مما هو عليه فعلاً. بعد قراءة المثال البسيط عن الأشكال والألوان، دعنا نفك شفرة الكلمات المخيفة في كتاب GoF.

التجريد (يُسمى أيضاً الواجهة) هو طبقة تحكم عالية المستوى لكيان ما. لا يُفترض أن تُنجز هذه الطبقة أي عمل حقيقي بنفسها، بل يجب أن تُفوِّض العمل إلى طبقة التنفيذ (يُسمى أيضاً المنصة).

لاحظ أننا لا نتحدث عن الواجهات أو الكلاسات التجريدية من لغة البرمجة الخاصة بك. هذه ليست الشيء نفسه.

عند الحديث عن التطبيقات الحقيقية، يمكن تمثيل التجريد بواجهة المستخدم الرسومية (GUI)، وقد يكون التنفيذ هو كود نظام التشغيل الأساسي (API) الذي تستدعيه طبقة واجهة المستخدم الرسومية استجابةً لتفاعلات المستخدم.

بشكل عام، يمكنك توسيع مثل هذا التطبيق في اتجاهين مستقلين:

• امتلاك عدة واجهات مستخدم رسومية مختلفة (على سبيل المثال، مُصمَّمة للعملاء العاديين أو المسؤولين).
• دعم عدة واجهات برمجة تطبيقات مختلفة (على سبيل المثال، للتمكن من تشغيل التطبيق على Windows وLinux وmacOS).

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

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

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

• التجريد: طبقة واجهة المستخدم الرسومية للتطبيق.
• التنفيذ: واجهات برمجة التطبيقات الخاصة بأنظمة التشغيل.

يتحكم كائن التجريد في مظهر التطبيق، مُفوِّضاً العمل الفعلي إلى كائن التنفيذ المرتبط به. التنفيذات المختلفة قابلة للتبادل طالما أنها تتبع واجهة مشتركة، مما يتيح لنفس واجهة المستخدم الرسومية العمل على Windows وLinux.

نتيجةً لذلك، يمكنك تغيير كلاسات واجهة المستخدم الرسومية دون المساس بالكلاسات المتعلقة بواجهة برمجة التطبيقات. علاوة على ذلك، إضافة دعم لنظام تشغيل آخر تستلزم فقط إنشاء كلاس فرعي في تسلسل التنفيذ الهرمي.

يوضح هذا المثال كيف يمكن لنمط الجسر تقسيم الكود الضخم لتطبيق يدير الأجهزة وأجهزة التحكم عن بُعد الخاصة بها. تعمل كلاسات Device كتنفيذ، في حين تعمل كلاسات Remote كتجريد.

يُعلن كلاس جهاز التحكم الأساسي عن حقل مرجع يربطه بكائن الجهاز. تعمل جميع أجهزة التحكم مع الأجهزة عبر واجهة الجهاز العامة، مما يتيح لجهاز التحكم ذاته دعم أنواع متعددة من الأجهزة.

يمكنك تطوير كلاسات أجهزة التحكم بشكل مستقل عن كلاسات الأجهزة. كل ما تحتاجه هو إنشاء كلاس فرعي جديد لجهاز التحكم. على سبيل المثال، قد يحتوي جهاز التحكم الأساسي على زرين فقط، لكن يمكنك توسيعه بميزات إضافية، كبطارية إضافية أو شاشة تعمل باللمس.

يربط كود العميل النوع المطلوب من جهاز التحكم بكائن جهاز محدد عبر مُنشئ جهاز التحكم.

// يُعرِّف "التجريد" الواجهةَ للجزء "التحكمي"
// من التسلسلين الهرميين للكلاسات. ويحتفظ بمرجع
// لكائن من تسلسل "التنفيذ" الهرمي ويُفوِّض
// كل العمل الفعلي لهذا الكائن.
class RemoteControl is
    protected field device: Device
    constructor RemoteControl(device: Device) is
        this.device = device
    method togglePower() is
        if (device.isEnabled()) then
            device.disable()
        else
            device.enable()
    method volumeDown() is
        device.setVolume(device.getVolume() - 10)
    method volumeUp() is
        device.setVolume(device.getVolume() + 10)
    method channelDown() is
        device.setChannel(device.getChannel() - 1)
    method channelUp() is
        device.setChannel(device.getChannel() + 1)


// يمكنك توسيع الكلاسات من تسلسل التجريد الهرمي
// بشكل مستقل عن كلاسات الأجهزة.
class AdvancedRemoteControl extends RemoteControl is
    method mute() is
        device.setVolume(0)


// تُعلن واجهة "التنفيذ" عن أساليب مشتركة لجميع
// كلاسات التنفيذ الملموسة. ولا يلزم أن تتطابق مع
// واجهة التجريد. في الواقع، قد تكون الواجهتان مختلفتين تماماً.
// عادةً توفر واجهة التنفيذ عمليات أساسية فقط، بينما
// يُعرِّف التجريد عمليات أعلى مستوى بناءً على تلك العمليات الأساسية.
interface Device is
    method isEnabled()
    method enable()
    method disable()
    method getVolume()
    method setVolume(percent)
    method getChannel()
    method setChannel(channel)


// جميع الأجهزة تتبع نفس الواجهة.
class Tv implements Device is
    // ...

class Radio implements Device is
    // ...


// في مكان ما في كود العميل.
tv = new Tv()
remote = new RemoteControl(tv)
remote.togglePower()

radio = new Radio()
remote = new AdvancedRemoteControl(radio)

1. حدِّد الأبعاد المتعامدة في كلاساتك. هذه المفاهيم المستقلة يمكن أن تكون: التجريد/المنصة، والمجال/البنية التحتية، والواجهة الأمامية/الخلفية، أو الواجهة/التنفيذ.

2. تعرَّف على العمليات التي يحتاجها العميل وعرِّفها في كلاس التجريد الأساسي.

3. حدِّد العمليات المتاحة على جميع المنصات. أعلِن عن العمليات التي يحتاجها التجريد في واجهة التنفيذ العامة.

4. لجميع المنصات في مجالك، أنشئ كلاسات تنفيذ ملموسة، لكن تأكد من أنها جميعها تتبع واجهة التنفيذ.

5. داخل كلاس التجريد، أضف حقل مرجع لنوع التنفيذ. يُفوِّض التجريد معظم العمل إلى كائن التنفيذ المُشار إليه في ذلك الحقل.

6. إذا كان لديك عدة متغيرات من المنطق عالي المستوى، فأنشئ تجريدات مُحسَّنة لكل متغير بتوسيع كلاس التجريد الأساسي.

7. يجب أن يمرر كود العميل كائن تنفيذ إلى مُنشئ التجريد لربطهما ببعض. بعد ذلك يمكن للعميل نسيان أمر التنفيذ والعمل فقط مع كائن التجريد.

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

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

• يمكنك استخدام المصنع التجريدي جنباً إلى جنب مع الجسر. هذا الترادف مفيد عندما يمكن لبعض التجريدات المُعرَّفة بواسطة الجسر أن تعمل فقط مع تنفيذات محددة. في هذه الحالة، يمكن للمصنع التجريدي تغليف هذه العلاقات وإخفاء التعقيد عن كود العميل.

• يمكنك دمج المنشئ مع الجسر: يؤدي كلاس المخرج دور التجريد، بينما تعمل المنشئات المختلفة كتنفيذات.