State Pattern in Swift
بیایم از طرح مسئله و حلش این الگو رو توضیح بدیم، خب مسئله ما چی بود؟
به ساده ترین حالت فرض میکنیم یه آسانسور داریم که ۴ تا دکمه داره، دکمه های:
- باز کردن
- بستن
- جابجایی
- توقف
ما باتوجه به اینکه آسانسور تو چه وضعیتی هستش میایم کاریی که این دکمه ها برای ما انجام میدن رو پیاده سازی میکنیم
مثلا وقتی آسانسور بسته هستش و ما دکمه باز کردن رو فشار میدیم در آسانسور باز میشه ولی اگر موقع حرکت کردن دکمه باز کردن رو فشار بدیم دستگاه بهمون هشدار میده که در حین حرکت در آسانسور نمیتونه باز باشه، به همین خاطر ما باید همیشه حواسمون باشه که تو چه مرحله ای چه دکمه ای فشار داده میشه
توی پروژه اول این پیاده سازی ها انجام شده و میبینیم که شروط تو در توی زیادی داخلش هست که موقع خوندن کد و یا دیباگ کردنش آدم اعصابش بهم میریزه حالا تصور کن که تعداد حالت ها و تعداد دکمه ها چند برابر بشه! رسما فاجعه پیش میاد برای خوندن خوندن کد ها 🤯🤬
توی این حالت ما میتونیم State Pattern رو استفاده بکنیم 😎
اگه بخوایم درمورد الگوی State بخونیم یک عالمه مطلب وجود داره و صرفا تو این پروژه من نحوه استفاده‌ش رو انجام دادم که مقایسه ای بشه با حالت بدون الگو
مواد لازم
یک عدد پروتکل شامل متد هایی ک لازم داریم مثلا فشار دادن دکمه باز کردن آسانسور، متن روی نمایشگر، آیا موزیک در حال پلی هستش یا نه و چه و چه، شبیه این چیزی که الان نوشته شده
و به تعداد حالاتی که آسانسور ما داره، کلاس هایی میسازیم که از این پروتکل ارث‌بری کرده باشن که به صورت زیر مشاهده میشه
حالت بسته بودن در آسانسور:
حالت در حال حرکت آسانسور:
حالت باز بودن در آسانسور:
حالت متوقف در آسانسور:
تا اینجاشو خیلی خوب پیش رفتیم
و حالا میرسیم به اصل کاریه که یه کلاسی هستش که یه آبجتکی از State رو داخل خودش نگه میداره، که همه جا بهش میگن Context و من اسمش رو گذاشتم Elevator و تمامی انتظاراتی که داریم رو هم داخلش مینویسیم، دقیقا مثل زیر که اکشن هایی که روی آسانسور انجا میشه تا State آسانسور تعیین بشه و اطلاعاتی که از State ها میخوایم رو بر حسب نیاز توش میاریم مثلا فشار دادن دکمه های آسانسور، گرفتن اطلاعاتی مثل رنگ چراغ آسانسور و و و و …
دیگه اینجا کار تمومه و همه چی آمادست، حالا کافیه یه نمونه از کلاس Elevator بسازیم و دیگ باهاش حال کنیم از راحتی کار 😍
مثل چیزی که توی main نوشته شده اگه پروژه رو Run کنیم میتونیم به ترتیب لاگ های پروژه رو ببینیم که وضعیت ها چطوری تغییر کردن
و اینم نتیجه لاگ
خب حالا مگه سرمون درد میکرد که از این استفاده کردیم و این همه کلاس ساختیم؟
باید بگم آره 😏
چرا؟ 🤔
به چند دلیل:
۱- کد مربوط به state هاداخل کلاس‌های جداگونه سازماندهی میشن — اصل Single Responsibility
۲- حالتا یا state های جدید، بدون تغییر توی کلاسای State قبلی یا کلاس Elevator معرفی میشن — اصل Open/Closed
۳- یه عالمه شرط و شروط سرسام آور از توی Elevator حذف شد که کلی خوندن و نگهداری کد رو راحت میکنه
راستی فایل های پروژه‌ای که درموردش حرف زدیم رو میتونین از گیت‌هاب دانلود کنین
⚠️ فقط حواسمون باشه که استفاده کردن از State Pattern برای وقتایی که تعداد حالات و یا اکشن های مسئله کم هستن ممکنه فقط باعث پیچیدگی کد بشه، پس حواسمون باشه که ما از Pattern ها استفاده میکنیم که مشکلات مارو حل بکنن نه اینکه یه مشکلی به مشکلای قبلیمون اضافه بشه 😁.
