ما،‌ الگوهای معماری، الگوریتم‌ها-بخش۱ ports & adaptors

سلام،‌این پست اولین پست وبلاگی من هست و امیدوارم اگه مشکلاتی داشت مخصوصا در مورد موضوع خوشحال می‌شم به من اطلاع بدید


حالا داستان چیه؟‌ اولا بگم که من دولوپر ارشد نیستم و درحال یادگیری‌ام،‌ ولی تازگی‌ها توی سایت‌های مختلف و گروه‌های برنامه نویسی می‌بینم خیلی‌ها به دیزاین پترن‌ها و الگوریتم ها گیر میدن، نه فقط در ایران قضیه توی زبان انگلیسی هم خیلی تکرار میشه احتمالا تا الآن باید حداقل یکبار این توییت وایرال شده رو دیدید

توییت وایرال شده در باره الگوریتن ها

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

تو این بخش قصد دارم درباره‌ی کاربرد دیزاین پترن Mediator و command بنویسم و کاربردش توی راحت تر کردن کار اجرای الگوی معماری معروف به پورت ها و آداپتورها یا همون معماری هشت ضلعی Hexagonal architecture.

احتمالا اگه تا الآن در حال کار کردن با الگوی طراحی هشت ظلعی،‌ به جایی رسیدید که تعداد زیادی لایه بیرونی خواهید داشت که نیاز به استفاده از لایه اپلیکیشن داشته باشند،‌ درست مثل نمونه تصویر اول پست. مثلا بخش گزارش گیری نیاز داره درباره مدل‌های اپ خبر داشته باشه و همینطور رابط گرافیکی و همزمان API ها و بخش مربوط به تست ها،‌ هم همینطور،‌ حالا چی میشه اگه شما بخوای اینترفیس (Interface) بخش کامندها بکنید چی میشه؟ با فرض بر اینکه شما از اصل Dependency inversion پیروی کردید و حالا نیازمندی های بخش مدل‌ها عوض شده مثلا فکر کنید در حال اجرای اپلیکیشنی مثل گوگل میت هستید و حالا میخواید بخش کلندر رو تازه اضافه کنید. و وقتی که کسی براش جلسه ست شده یا لغو شد یا هر اتفاقی تغییری توی استیت شون افتاد ایمیل بفرستید برای کاربرها و میخواید ایمیل رو به صورت async بفرستید. چندتا از سرویس‌ها تو رو باید ریفکتور کنید؟ وقتی که ارسال ایمیل اضافه شد باید همه سرویس هایی که از مدل های داخلی استفاده میکنند باید ریفکتور بشن.

حالا اینجا دیزاین پترن‌های میدیتور و کامند به کار میان و میتونن کمک کنند. اما چطور؟

اول یه نگاهی به خود دیزاین پترن ها بندازیم:‌

اول Mediator

دیزاین پترن میدیتور

خلاصه این دیزاین پترن اینه که هرجا دیدید لایبرری‌ها تون نیاز دارن درباره همدیگه بدونن و تعداد بخش هایی که قراره از هم بدونن زیاده بیاید یه کلاس(یا لایبرری) بزارید وسطش که همه با اون کلاس کار کنن و اون کلاس در باره همه لایه های زیریش(تو تصویر بالا قسمت سمت راست) بدونه و بدونه کدوم ورودی رو به کدوم خروجی وصل کنه. در اصل بخش سمت راست خودش ور برای مدیتور داوطلب انجام کاری که بخش چپ درخواست میکنه، میکنه جالبی مدیتور اینه که میتونه اصلا بخشی از کد شما نباشه مثلا مسیج بروکر هایی مثل RabbitMQ یا مثلا Redis.

دیزاین پترن command

بهترین توصیف کامند

خلاصه این یکی دیزاین پترن اینه که هروقت تسکی داشتید که میخواست استیت رو عوض کنه و نیاز بود از جاهای مختلفی اینکار انجام بشه (مثل دکمه سیو که هم ctrl+s هست هم تو منو فایل هم توی آیکون سیو) بیاید و اون تست رو بدید به کلاس جدا گونه برای انجامش و از هرجا لازم شد فقط متد execute روی اون کلاس رو کال کنید تو مدل گوگل میت که بالاتر گفتم میشه sessionManger.AddNewSession(sessionInfo) دیگه کار فرستادن ایمیل و اضافه کردن دیتا بیس و اینا همه با سشن منیجره.

خب حالا چطور اینا کمک میکنن که ما کدمون راحت تر منیج بشه؟

با استفاده از ترکیب مدیتور و کامند میشه اجرای بخش ثبت اتفاقات و ایمیل فرستادن رو کاملا از سرویس ها مخفی کرد و فقط متدهایی رو که تسک های ساختن جلسات و ارسال ایمیل رو هم زمان برای مدیتور register کرد و سرویس ها فقط توی خودشون به مدیتور بگن میخوام کامند ثبت جلسه اجرا بشه، همین

چیزی مثل ساختار مدل زیر که اشتباهاتی توی درست کردنش داشتم ولی بخش قرمز در اصل اون مدیتور ماست و بخش های قرمز واسط های اجرای لاجیک اصلی یا بیزینس لاجیکمون هستن

اگه اشتباه نگارشی داشت معذرت میخوام و خوشحال میشم بم تو کامنتا بگید

اگه اشتباه فنی هم داشت بازم خوشحال میشم بگید و کمک کنید بیشتر یاد بگیرم.

ممنون

نوشته ما،‌ الگوهای معماری، الگوریتم‌ها-بخش۱ ports & adaptors اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

دیدگاهتان را بنویسید