قبلی

الگوی مدیاتور - قسمت اول
8/16/2022 10:31:24 AM

بعدی

Mediator vs Bridge vs Adapter pattern
/8/18/2022 4:32:13 AM
news-d14f90a1b81.jpg
معماری نرم افزار - الگو های نرم افزار الگوی مدیاتور - قسمت دوم

Mediator

مثالی کاربردی برای درک بهتر دیزاین پترن مدیاتور که از مهم ترین الگوهای نرم افزاری برای بهبود عملکرد در مدیریت تزریق وابستگی در پروژه میباشد .

 

1.الزامات توسط مشتری برای میانجی(mediator) ارسال می شود و میانجی الزامات را به تیم توسعه ارسال می کند.

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

 

1.1.کلاس abstract مشتری یک مرجع از واسطه دریافت خواهد کرد. با استفاده از این مرجع، با فراخوانی متد ReceieveRequirementsFromClient() در میانجی، الزامات به واسطه تحویل داده می شود.

 

2.1.Mediator با فراخوانی متد ReceieveRequirementsFromMediator(client) با استفاده از مرجع DevTeam که در اختیار دارد، این موارد را به DevTeam ارسال می کند. این متد در کلاس DevTeam قرار دارد. جزئیات دریافت شده توسط تیم توسعه روی صفحه نمایش داده می شود. کد زیر را ببینید.:

 

mediator

 

کد مشتری ما برای شروع فرآیند مانند زیر خواهد بود : 

 

mediatorPattern

 

عملکرد مرحله اول :

برای شروع فرآیند، یک مرجع (میانجی - mediator) جدید ایجاد می‌شود و به کلاس‌های توسعه‌دهنده و کلاینت داده می‌شود تا به آنها اجازه دهد از آن برای ارسال پیام‌ها استفاده کنند.

 

در همان زمان، کلاس Mediator مراجع تیم های مشتری و توسعه دهنده را برای تکمیل فرآیند ارتباط دریافت می کند. در اینجا می بینیم که هیچ یک از کلاس های تیم کلاینت و توسعه دهنده مستقیماً با یکدیگر تعامل ندارند. این منجر به یک سیستم با اتصال آزاد می شود.

 

عملکرد مرحله دوم :

DevTeam سوالاتی را برای واسطه ارسال می کند و واسطه آنها را به client ارسال می کند.

در این مرحله، تیم توسعه کوئری را برای میانجی ارسال می‌کند و میانجی آن را برای client ارسال می‌کند. مانند کد بالا، تیم dev-تیمی در کلاس abstract خود برای ارسال پرس و جو به واسطه خواهد داشت.

 

همانند بالا، تیم توسعه دهنده مرجع واسطه را از طریق کلاس abstract تیم توسعه دهنده خود دریافت می کند. با استفاده از این مرجع، متد ReceiveQueryFromDevTeam واسطه را فراخوانی می کند.

Mediator به کلاس Client اشاره دارد. Mediator از این مرجع برای فراخوانی متد ReceiveQueryFromMediator از کلاس کلاینت استفاده خواهد کرد. این روش به سادگی جزئیاتی را که دارد چاپ می کند. کد زیر را ببینید:

mediator3

 

از آنجایی که قبلاً مرجع میانجی را برای کلاس های کلاینت و dev-team و مراجع این کلاس ها را برای واسطه در مرحله 1 تنظیم کرده ایم، به سادگی نیاز داریم که SendQueryToMediator() کلاس dev-team را فراخوانی کنیم. بنابراین کد مشتری به صورت زیر خواهد بود:

mediator

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

آموزش های مرتبط

نظر ها

---

ثبت نظر