الگوی میانجی چیست؟

تصور کنید در یک فرودگاه، برج مراقبت وجود ندارد. هر هواپیما برای فرود، برخاستن یا تغییر مسیر، باید مستقیماً با تمام هواپیماهای دیگر در ارتباط باشد. نتیجه چنین وضعیتی، یک آشفتگی کامل، پیچیدگی غیرقابل مدیریت و ریسک بالای برخورد خواهد بود. برج مراقبت در این سناریو، نقش یک میانجی را ایفا می‌کند. هواپیماها دیگر نیازی به ارتباط مستقیم با یکدیگر ندارند؛ آن‌ها تمام اطلاعات و درخواست‌های خود را به برج مراقبت ارسال می‌کنند و برج مراقبت، با در اختیار داشتن دید کامل از وضعیت، ارتباطات را هماهنگ کرده و دستورات لازم را صادر می‌کند.

الگوی میانجی در نرم‌افزار نیز دقیقاً همین نقش را بر عهده دارد. به جای اینکه مجموعه‌ای از اشیاء (که به آن‌ها Colleagues یا همکاران گفته می‌شود) مستقیماً به یکدیگر ارجاع داشته باشند و متدهای یکدیگر را فراخوانی کنند، همگی یک شیء میانجی را می‌شناسند. هر همکار، رویدادها و تغییرات وضعیت خود را به میانجی اطلاع می‌دهد و میانجی تصمیم می‌گیرد که کدام یک از همکاران دیگر باید از این رویداد مطلع شوند و چه واکنشی نشان دهند.

این الگو، شبکه پیچیده ارتباطات "همه با همه" را به یک ساختار ستاره‌ای ساده "همه با یک" تبدیل می‌کند که درک و مدیریت آن به مراتب آسان‌تر است.

مزایای کلیدی استفاده از الگوی میانجی

به کارگیری این الگو می‌تواند فواید قابل توجهی برای معماری نرم‌افزار به همراه داشته باشد.

۱. کاهش چشمگیر وابستگی‌ها (Loose Coupling)

• مهم‌ترین و اصلی‌ترین مزیت الگوی میانجی، کاهش وابستگی بین اجزای سیستم است. در غیاب این الگو، هر شیء باید ارجاع مستقیمی به تمام اشیائی که با آن‌ها در تعامل است، داشته باشد. این وابستگی‌های شدید باعث می‌شود که تغییر در یک جزء، به صورت آبشاری نیازمند تغییرات در اجزای متعدد دیگری باشد.

با وجود میانجی، همکاران دیگر نیازی به شناختن یکدیگر ندارند. آن‌ها فقط میانجی را می‌شناسند. این استقلال به این معناست که می‌توان یک همکار را بدون تأثیرگذاری بر سایر همکاران، تغییر داد یا حتی با یک پیاده‌سازی جدید جایگزین کرد. این ویژگی، که به آن "اتصال سست" یا Loose Coupling می‌گویند، نگهداری و توسعه سیستم را به شدت تسهیل می‌کند.

۲. تمرکز و کپسوله‌سازی منطق تعاملات

منطق پیچیده‌ای که نحوه تعامل اجزا با یکدیگر را مشخص می‌کند، به جای پراکنده شدن در کلاس‌های مختلف، به طور کامل در یک مکان واحد (شیء میانجی) متمرکز و کپسوله می‌شود. این امر پیروی از اصل مسئولیت واحد (Single Responsibility Principle) را تقویت می‌کند. همکاران فقط مسئول انجام وظایف اصلی خود هستند و مسئولیت نحوه ارتباط با دیگران بر عهده میانجی است. این تمرکز، فهم، خطایابی و اصلاح منطق تعاملات را بسیار ساده‌تر می‌سازد.

۳. افزایش قابلیت استفاده مجدد (Reusability)

از آنجایی که اجزای همکار (Colleagues) دیگر وابستگی مستقیمی به یکدیگر ندارند، می‌توان آن‌ها را به راحتی در سیستم‌های دیگر یا سناریوهای متفاوت مجدداً استفاده کرد. برای مثال، یک کامپوننت دکمه که در یک فرم پیچیده طراحی شده و از طریق یک میانجی با سایر عناصر فرم در ارتباط است، می‌تواند به سادگی در فرم دیگری با یک میانجی متفاوت به کار گرفته شود، بدون آنکه نیازی به تغییر در کد داخلی خود دکمه باشد.

۴. سادگی در توسعه و اصلاح سیستم

• با پیروی از اصل باز/بسته (Open/Closed Principle)، می‌توان رفتار سیستم را با معرفی پیاده‌سازی‌های جدید از میانجی تغییر داد، بدون آنکه نیازی به دستکاری کد همکاران باشد. اگر نیاز به افزودن یک تعامل جدید بین دو جزء وجود داشته باشد، کافی است این منطق در کلاس میانجی پیاده‌سازی شود. این رویکرد، فرآیند توسعه و اعمال تغییرات را بسیار چابک‌تر و کم‌خطرتر می‌کند.

مثال کاربردی: یک مثال کلاسیک برای الگوی میانجی، دیالوگ‌های رابط کاربری (UI) است. فرض کنید یک فرم ثبت‌نام دارید که شامل چندین فیلد متنی، چک‌باکس و یک دکمه "ثبت" است. ممکن است قوانینی وجود داشته باشد؛ مثلاً اگر چک‌باکس "پذیرش قوانین" تیک نخورده باشد، دکمه "ثبت" باید غیرفعال باشد. به جای اینکه چک‌باکس مستقیماً دکمه را غیرفعال کند، رویداد "تغییر وضعیت" خود را به میانجی (که می‌تواند خود کلاس دیالوگ باشد) اطلاع می‌دهد. سپس میانجی تصمیم می‌گیرد که بر اساس این رویداد، وضعیت دکمه را تغییر دهد.

معایب و چالش‌های الگوی میانجی

با وجود تمام مزایا، استفاده نادرست یا بیش از حد از این الگو می‌تواند منجر به بروز مشکلاتی در معماری سیستم شود.

۱. خطر ایجاد شیء خدا (God Object)

• بزرگترین و شایع‌ترین عیب الگوی میانجی، این است که خود شیء میانجی می‌تواند به مرور زمان به یک کلاس بسیار بزرگ، پیچیده و غیرقابل نگهداری تبدیل شود. با افزایش تعداد همکاران و تعاملات، تمام این منطق‌ها در کلاس میانجی انباشته می‌شود. این پدیده که به "ضدالگوی شیء خدا" (God Object Anti-pattern) معروف است، تمام مزایای تمرکزگرایی را از بین می‌برد و خود به یک گلوگاه (Bottleneck) برای توسعه و نگهداری تبدیل می‌شود. یک میانجی بیش از حد پیچیده، درک و اصلاح کد را دشوار کرده و اصل مسئولیت واحد را در سطح خود نقض می‌کند.

۲. پیچیدگی اولیه

• برای سیستم‌های ساده با تعداد محدودی تعامل، معرفی یک میانجی ممکن است یک لایه پیچیدگی غیرضروری اضافه کند. در چنین مواردی، ارتباط مستقیم بین اشیاء می‌تواند راه حل ساده‌تر و سرراست‌تری باشد. ارزیابی دقیق پیچیدگی تعاملات قبل از پیاده‌سازی این الگو ضروری است.

۳. کاهش کارایی در برخی سناریوها

• اگرچه در اکثر کاربردها قابل چشم‌پوشی است، اما ارتباط غیرمستقیم از طریق میانجی می‌تواند بار پردازشی (overhead) اندکی را به سیستم تحمیل کند. هر ارتباط نیازمند یک فراخوانی اضافی به میانجی و سپس از میانجی به گیرنده است. در سیستم‌هایی که کارایی در سطح بسیار بالایی اهمیت دارد و میلیون‌ها پیام در ثانیه رد و بدل می‌شود، این تأخیر جزئی ممکن است تأثیرگذار باشد.

چه زمانی باید از الگوی میانجی استفاده کرد؟

استفاده از این الگو در شرایط زیر توصیه می‌شود:

• وابستگی‌های درهم‌تنیده: زمانی که مجموعه‌ای از اشیاء به شکلی پیچیده و درهم‌تنیده با یکدیگر در ارتباط هستند و درک و نگهداری این ارتباطات دشوار شده است.

• نیاز به قابلیت استفاده مجدد: هنگامی که می‌خواهید اجزای سیستم را به گونه‌ای طراحی کنید که مستقل باشند و بتوان آن‌ها را به راحتی در زمینه‌های دیگر استفاده کرد.

• منطق ارتباطی متمرکز: زمانی که منطق کنترل تعاملات بین چندین شیء وجود دارد و نمی‌خواهید این منطق را در خود آن اشیاء پراکنده کنید.

 نتیجه‌گیری

الگوی طراحی میانجی یک ابزار قدرتمند برای مدیریت پیچیدگی در سیستم‌های نرم‌افزاری است. این الگو با ترویج اتصال سست (Loose Coupling) و متمرکز کردن منطق تعاملات، به ساخت سیستم‌هایی منجر می‌شود که نگهداری، توسعه و درک آن‌ها آسان‌تر است. با این حال، معماران و توسعه‌دهندگان باید همواره مراقب بزرگترین خطر این الگو، یعنی تبدیل شدن میانجی به یک "شیء خدا"، باشند. با طراحی دقیق و تقسیم مسئولیت‌ها، می‌توان از مزایای این الگو بهره‌مند شد و از معایب آن دوری جست. انتخاب هوشمندانه زمان و نحوه به کارگیری الگوی میانجی، کلید دستیابی به یک معماری تمیز، انعطاف‌پذیر و مقیاس‌پذیر است.