الوكيل.

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

لماذا تريد التحكم في الوصول إلى كائن ما؟ إليك مثال: لديك كائن ضخم يستهلك قدراً هائلاً من موارد النظام. تحتاجه من وقت لآخر، لكن ليس دائماً.

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

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

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

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

يوضح هذا المثال كيف يمكن لنمط الوكيل المساعدة في تقديم التهيئة الكسولة والتخزين المؤقت لمكتبة تكامل YouTube من طرف ثالث.

The library provides us with the video downloading class. However, it’s very inefficient. If the client application requests the same video multiple times, the library just downloads it over and over, instead of caching and reusing the first downloaded file.

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

// واجهة خدمة بعيدة.
interface ThirdPartyYouTubeLib is
    method listVideos()
    method getVideoInfo(id)
    method downloadVideo(id)

// التطبيق الملموس لموصّل الخدمة. يمكن لطرق
// هذه الفئة طلب معلومات من YouTube. تعتمد سرعة
// الطلب على اتصال المستخدم بالإنترنت
// وكذلك على YouTube. سيبطؤ التطبيق إذا أُرسلت كثير من
// الطلبات في نفس الوقت، حتى وإن طلبت جميعها
// نفس المعلومات.
class ThirdPartyYouTubeClass implements ThirdPartyYouTubeLib is
    method listVideos() is
        // إرسال طلب API إلى YouTube.

    method getVideoInfo(id) is
        // الحصول على بيانات وصفية لمقطع فيديو.

    method downloadVideo(id) is
        // تنزيل ملف فيديو من YouTube.

// لتوفير عرض النطاق الترددي، يمكننا تخزين نتائج الطلبات مؤقتاً والاحتفاظ
// بها لبعض الوقت. لكن قد يكون من المستحيل وضع هذا الكود
// مباشرةً في فئة الخدمة. على سبيل المثال، ربما تم
// تقديمه كجزء من مكتبة طرف ثالث و/أو تعريفه
// بـ `final`. لهذا السبب نضع كود التخزين المؤقت في
// فئة وكيل جديدة تُنفذ نفس الواجهة التي تُنفذها
// فئة الخدمة. تفوض إلى كائن الخدمة فقط عندما
// يجب إرسال الطلبات الحقيقية.
class CachedYouTubeClass implements ThirdPartyYouTubeLib is
    private field service: ThirdPartyYouTubeLib
    private field listCache, videoCache
    field needReset

    constructor CachedYouTubeClass(service: ThirdPartyYouTubeLib) is
        this.service = service

    method listVideos() is
        if (listCache == null || needReset)
            listCache = service.listVideos()
        return listCache

    method getVideoInfo(id) is
        if (videoCache == null || needReset)
            videoCache = service.getVideoInfo(id)
        return videoCache

    method downloadVideo(id) is
        if (!downloadExists(id) || needReset)
            service.downloadVideo(id)

// تبقى فئة واجهة المستخدم الرسومية (GUI)، التي كانت تعمل مباشرةً مع
// كائن خدمة، دون تغيير طالما تعمل مع كائن الخدمة
// عبر واجهة. يمكننا بأمان تمرير كائن وكيل
// بدلاً من كائن خدمة حقيقي لأن كليهما
// يُنفذ نفس الواجهة.
class YouTubeManager is
    protected field service: ThirdPartyYouTubeLib

    constructor YouTubeManager(service: ThirdPartyYouTubeLib) is
        this.service = service

    method renderVideoPage(id) is
        info = service.getVideoInfo(id)
        // عرض صفحة الفيديو.

    method renderListPanel() is
        list = service.listVideos()
        // عرض قائمة مصغّرات الفيديو.

    method reactOnUserInput() is
        renderVideoPage()
        renderListPanel()

// يمكن للتطبيق تهيئة الوكلاء أثناء التشغيل.
class Application is
    method init() is
        aYouTubeService = new ThirdPartyYouTubeClass()
        aYouTubeProxy = new CachedYouTubeClass(aYouTubeService)
        manager = new YouTubeManager(aYouTubeProxy)
        manager.reactOnUserInput()

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

2. أنشئ فئة الوكيل. يجب أن تحتوي على حقل لتخزين مرجع للخدمة. عادةً ما ينشئ الوكلاء دورة حياة خدماتهم بالكامل ويديرونها. في حالات نادرة، يتم تمرير الخدمة إلى الوكيل عبر المُنشئ من قِبل العميل.

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

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

5. فكّر في تطبيق التهيئة الكسولة لكائن الخدمة.

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

• الواجهة الخارجية (Facade) مشابهة لـ الوكيل (Proxy) في أن كليهما يُخزّن كياناً معقداً ويُهيئه بمفرده. على عكس الواجهة الخارجية، يمتلك الوكيل نفس واجهة كائن خدمته، مما يجعلهما قابلَين للتبادل.

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