سلام،این پست اولین پست وبلاگی من هست و امیدوارم اگه مشکلاتی داشت مخصوصا در مورد موضوع فنی و نگارش، به من اطلاع بدید
حالا داستان چیه؟ اولا بگم که من دولوپر ارشد نیستم و درحال یادگیری‌ام، ولی تازگی‌ها توی سایت‌های مختلف و گروه‌های برنامه نویسی می‌بینم خیلی‌ها به دیزاین پترن‌ها و الگوریتم ها گیر میدن که فقط به درد مصاحبه میخوره، نه فقط در ایران قضیه توی زبان انگلیسی هم خیلی تکرار میشه احتمالا تا الآن باید حداقل یکبار این توییت وایرال شده رو دیده باشید
خب به علت همین قضیه مجاب شدم چندتایی از دیزاین پترن‌ها و الگوریتم‌هایی که حداقل من می‌دونم خیلی کاربردی هستن رو اینجا درحد خودم توضیح بدم تا هم خودم بهتر یادبگیرم و هم شاید یه سری جوون ترها مجاب بشن الگوریتم و دیزاین پترن رو یاد بگیرن.
تو این بخش قصد دارم درباره‌ی کاربرد دیزاین پترن Mediator و command بنویسم و کاربردش توی راحت تر کردن کار اجرای الگوی معماری معروف به پورت ها و آداپتورها یا همون معماری شش ضلعی Hexagonal architecture.
احتمالا تا الآن در حال کار کردن با الگوی طراحی شش ظلعی، به جایی رسیدید که تعداد زیادی لایه بیرونی داشتید که نیاز به استفاده از لایه اپلیکیشن داشتند، درست مثل نمونه تصویر اول پست. مثلا بخش گزارش گیری نیاز داره درباره مدل‌های اپ خبر داشته باشه و همینطور رابط گرافیکی و همزمان API ها و بخش مربوط به تست ها، هم همینطور، حالا چی میشه اگه شما بخوای اینترفیس (Interface) بخش مربوط به بیزینس لاجیک رو عوض کنید؟ با فرض بر اینکه شما از اصل Dependency inversion پیروی کردید و حالا نیازمندی های بخش مدل‌ها عوض شده مثلا فکر کنید در حال اجرای اپلیکیشنی مثل گوگل میت هستید و حالا میخواید بخش کلندر رو تازه اضافه کنید. و وقتی که کسی براش جلسه ست شده یا لغو شد یا هر اتفاقی تغییری توی استیت شون افتاد ایمیل بفرستید و یه سری ریسپانس‌ها رو برای کاربر بفرستید که تا الان نمی فرستادید. چندتا از سرویس‌ها تو رو باید ریفکتور کنید؟ وقتی که ارسال ایمیل اضافه شد باید همه سرویس هایی که از مدل های داخلی استفاده میکنند ریفکتور بشن.
حالا اینجا دیزاین پترن‌های میدیتور و کامند به کار میان و میتونن کمک کنند. اما چطور؟
اول یه نگاهی به خود دیزاین پترن ها بندازیم:
اول Mediator
خلاصه این دیزاین پترن اینه که هرجا دیدید لایبرری‌ها تون نیاز دارن درباره همدیگه بدونن و تعداد بخش هایی که قراره از هم بدونن زیاده بیاید یه کلاس(یا لایبرری) بزارید وسطش که همه با اون کلاس کار کنن و اون کلاس در باره همه لایه های زیریش(تو تصویر بالا قسمت سمت راست) بدونه و بدونه کدوم ورودی رو به کدوم خروجی وصل کنه. در اصل بخش سمت راست خودش رو برای مدیتور داوطلب انجام کاری که بخش چپ درخواست میکنه، میکنه جالبی مدیتور اینه که میتونه اصلا بخشی از کد شما نباشه مثلا مسیج بروکر هایی مثل RabbitMQ یا مثلا Redis.
دیزاین پترن command
خلاصه این یکی دیزاین پترن اینه که هروقت تسکی داشتید که میخواست استیت رو عوض کنه و نیاز بود از جاهای مختلفی اینکار انجام بشه (مثل دکمه سیو که هم ctrl+s هست هم تو منو فایل هم توی آیکون سیو) بیاید و اون تست رو بدید به کلاس جدا گونه برای انجامش و از هرجا لازم شد فقط متد execute روی اون کلاس رو کال کنید تو مدل گوگل میت که بالاتر گفتم میشه
NewSessionCommand.execute(sessionInfo)
که اینجا ما چون مدیتور داریم این مدلی تغییرش میدیم
Mediator.Send (new CreateSessionEvent(sessionInfo))
دیگه کار فرستادن ایمیل و اضافه کردن دیتا بیس و اینا همه با هندلر مربوط به تولید سشن هست که مدیتور کالش میکنه.
خب حالا چطور اینا کمک میکنن که ما کدمون راحت تر نگه‌داری بشه؟
با استفاده از ترکیب مدیتور و کامند میشه اجرای بخش ثبت اتفاقات و ایمیل فرستادن رو کاملا از سرویس ها مخفی کرد و فقط متدهایی رو که تسک های ساختن جلسات و ارسال ایمیل رو هم زمان برای مدیتور register کرد و سرویس ها فقط توی خودشون به مدیتور بگن میخوام کامند ثبت جلسه اجرا بشه، همین.
چیزی مثل ساختار مدل زیر
این مدلی هر بخش یا سرویسی که لازم داره با مدل‌ها ارتباط برقرار کنه بدون اینکه بدونه مدل چیه یا چطور کار میکنه خیلی راحت فقط یک ایونت برای اون عملیات ایجاد میکنه و تحویل مدیتور میده. حالا میتونید تا زمانی که ورودی‌ها تون یکسانه هر جوری دوست دارید خروجی‌های بخش هندلر مربوط به تولید سشن برای کاربرا رو عوض کنید.
اگه اشتباه نگارشی داشت معذرت میخوام و خوشحال میشم بم تو کامنتا بگید
اگه اشتباه فنی هم داشت بازم خوشحال میشم بگید و کمک کنید بیشتر یاد بگیرم.
ممنون
