شما آموزش‌های بی شماری از دستورات If-Else شاهد بوده‌اید. همچنین احتمالاً شما کتابهای برنامه نویسی را نیز خوانده اید که استفاده از If-Else را به عنوان تکنیک منشعب سازی عملاً ترویج می کنند.
شاید حتی استفاده از If-Else حالت پیش فرض ذهنی شما باشد. اما ، بیایید با جایگزینی If-Else با اشیا state به این مساله خاتمه دهیم.
توجه داشته باشید که اگر در حال نوشتن کلاسی با متدهایی هستید که نیاز به اجرای آن با توجه به وضعیت فعلی داشته باشید، از این رویکرد استفاده خواهید کرد.
شما به راحتی می توانید رفتار اشیا را با استفاده از الگوی state به جای عبارات If-Else تغییر دهید.
به کد زیر دقت کنید:
منطق انشعاب در بالا حتی خیلی پیچیده نیست. اما سعی کنید شرط جدیدی اضافه کنید تا ببینید که همه چیز منفجر می شود.
نرم افزار بهتر بدون (If/Else) : 5 راه برای جایگزینی
" بسیار خوب، من متقاعد شده‌ام که If-Else بد است، حالا به من نشان بده که چطور از تقسیم‌بندی درهم و برهم کد اجتناب کنم."
بیایید یک کلاس Booking بسیار ساده ایجاد کنیم که دارای چند حالت است. همچنین دارای دو متد عمومی است: Accept و Cancel .
من حالت های مختلف رزرو بلیط رو به این صورت تصویر کردم
منطق Refactoring کد ما یک فرآیند سه‌مرحله‌ای است:
اول از همه ، ما به یک کلاس پایه نیاز داریم که همه state ها از آن به ارث می برند.
توجه کنید که چگونه این کلاس پایه دارای دو متد Accept و Cancel است - اگرچه در اینجا internal مشخص شده اند.
علاوه بر این ، کلاس پایه، یک متد "ویژه" EnterState(Booking booking) دارد. هر زمان که state جدیدی به شی book اختصاص داده شود ، فراخوانی می شود.
ثانیا ، ما برای هر state که می خواهیم نمایندگی کنیم کلاسهای جداگانه ای در نظر می گیریم.
توجه کنید که چگونه هر کلاس یک state را نشان می‌دهد همانطور که در نمودار زیبای بالا توضیح داده شد. همچنین، CancelledState اجازه انتقال به یک state جدید را نخواهد داد. این کلاس بسیار شبیه به الگوی Null Object است.
سرانجام خود کلاس booking به این شکل خواهد بود.
ببینید چگونه کلاس booking به سادگی اجرای Accept و Cancel را به state object خود واگذار می کند؟
انجام این کار به ما امکان می دهد بسیاری از منطق های شرطی را حذف کنیم و به هر state اجازه می دهیم فقط بر روی آنچه برای خود مهم است تمرکز کند - state فعلی همچنین این امکان را دارد که booking را به state جدید منتقل کند.
اگر ویژگی جدید به طور معمول با استفاده از برخی بررسی های مشروط اجرا می شد ، اکنون می توانید فقط یک کلاس state جدید ایجاد کنید.
به همین سادگی. دیگر نیازی به کار با عبارت های نامطلوب if-else نیست.
تو این کار رو نمی‌کنی.تنها دانستن state object و چگونگی نگاشت آن به ستون مهم است.شما می‌توانید یک state را با یک نوع ، یک enum یا یک عدد صحیح نگاشت کنید. یا هر چیزی که با آن راحت هستی، تا وقتی که راهی برای تبدیل مقدار ذخیره‌شده به یک state object داشته باشید.
در واقع. همانطور که در مقاله دیگری اشاره کردم ، پیچیدگی از تعداد کلاسهایی که شما تشکیل می دهید ناشی نمی شود ، بلکه از مسئولیتهایی است که کلاسها بر عهده دارند. داشتن کلاسهای بسیار زیاد ، کد شما را قابل خواندن ، نگهداری و به طور کلی کار با آن لذت بیشتری می بخشد.
برگرفته شده از مدیوم Nicklas Millard
