مسئله‌ای که باید حل می‌کردم
انتخاب حکم از نظر رابط یک لمس هست، ولی از نظر قانون هر صندلی نمی‌تواند آن را انجام بدهد. من باید اختیار حاکم و آماده‌بودن مرحله را مستقل از دکمه بررسی می‌کردم.
پیاده‌سازی در نسخهٔ فعلی
HokmTrumpSelectionService.RequestTrumpSelection برای انسان حالت انتظار می‌سازد و برای ربات راهبرد IHokmTrumpSelectionStrategy را صدا می‌زند. SelectTrump صندلی درخواست‌دهنده و یکی از چهار خال معتبر را کنترل می‌کنه.
تصمیم و هزینهٔ طراحی
انسان و ربات دو ورودی متفاوت دارن، اما انتخاب نهایی به همان قرارداد می‌رسه. CanStartCardPlay به وضعیت انتخاب و کامل‌شدن پخش باقی کارت‌ها وابسته هست.
مرزهای فعلی
راهبرد ربات باید موجود باشد و دست نخست حاکم دقیقاً پنج کارت داشته باشد. این سرویس کیفیت انتخاب خال را تضمین نمی‌کنه؛ قانونی‌بودن انتخاب با خوب‌بودن استراتژی فرق داره.
ورودی انسانی و تصمیم بات در یک مسیر
در RequestTrumpSelection، ابتدا پیکربندی و صندلی حاکم بررسی می‌شوند و دست اولیه باید دقیقاً پنج کارت داشته باشد. سپس state برای دست تازه بازنشانی می‌شود. برای انسان، MarkWaitingForHumanSelection و رخداد HumanTrumpSelectionRequested درخواست رابط را تولید می‌کنند؛ سرویس منتظر انتخاب می‌ماند و خودش خال پیش‌فرضی را به جای بازیکن ثبت نمی‌کنه. این انتظار بخشی از قرارداد مرحله هست. برای طراحی رابط، نتیجهٔ WaitingForHuman باید از نتیجهٔ Selected قابل تشخیص باشد تا باز شدن پنجرهٔ انتخاب با پایان انتخاب اشتباه گرفته نشود.
برای بات، HokmTrumpSelectionContext یک فهرست کپی از همین پنج کارت، تیم، صندلی و خال‌های مجاز دریافت می‌کنه. استراتژی از آن context خال را انتخاب می‌کنه و نتیجه دوباره از SelectTrump عبور می‌کنه. این مسیر مشترک مهم هست، چون خروجی بات نباید فقط به دلیل ماشینی بودن از بررسی خال مجاز معاف باشد. اگر botStrategy وجود نداشته باشد، سرویس نتیجهٔ Rejected می‌دهد. بنابراین ساخت بات با تخصیص نوع کنترلر تمام نمی‌شود؛ وابستگی تصمیم‌گیری نیز باید هنگام ساخت سرویس حاضر باشد.
SelectTrump دو هویت requestingSeatId و hakemSeatId را مقایسه می‌کنه و تنها چهار خال استاندارد را می‌پذیرد، سپس SetTrump را روی state اجرا می‌کنه. نکتهٔ مرزی این هست که هویت حاکم به صورت پارامتر وارد این متد می‌شود؛ این کد سرویس احراز هویت شبکه نیست و صحت اتصال پارامترها همچنان مسئولیت فراخواننده هست. CanStartCardPlay هم انتخاب حکم را با remainingCardsDealt ترکیب می‌کنه. این جداسازی جلوی برداشت مفهومی غلط را می‌گیرد: انتخاب موفق حکم، به‌تنهایی ثابت نمی‌کنه بقیهٔ کارت‌ها تقسیم شده‌اند یا میز آمادهٔ پذیرش اولین حرکت هست.
چیزی که از این مرحله یاد گرفتم
من خواستم منطق اختیار از ظاهر انتخاب جدا بماند. این کار اجازه می‌دهد رابط تغییر کنه و ربات بهتر بشه، بدون اینکه امکان انتخاب حکم از صندلی اشتباه باز بشه.
مثال عملی انتخاب خال حکم
یک روش کاربردی برای بررسی انتخاب خال حکم این است که به جای چند تغییر هم‌زمان، تنها یک مسیر کوتاه بسازی. بازیکن با دست اولیه یکی از چهار خال را انتخاب می‌کند و تأیید می‌زند. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازه‌ای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمی‌شود.
خطای رایج و علت آن
اگر کلیک دو بار پردازش شود یا انتخاب دیر برسد، خال حکم ممکن است پس از شروع دور عوض شود. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. انتخاب موقت رابط تا زمان تأیید با حکم ثبت‌شدهٔ مسابقه فرق دارد. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
فقط حاکم و فقط در مرحلهٔ انتخاب باید بتواند یک خال معتبر را ثبت کند. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | بازیکن با دست اولیه یکی از چهار خال را انتخاب می‌کند و تأیید می‌زند. |
| ریسک اصلی | اگر کلیک دو بار پردازش شود یا انتخاب دیر برسد، خال حکم ممکن است پس از شروع دور عوض شود. |
| روش بررسی | فقط حاکم و فقط در مرحلهٔ انتخاب باید بتواند یک خال معتبر را ثبت کند. |
| مرز نتیجه‌گیری | انتخاب موقت رابط تا زمان تأیید با حکم ثبت‌شدهٔ مسابقه فرق دارد. |
پرسش‌های کاربردی دربارهٔ انتخاب خال حکم
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: بازیکن با دست اولیه یکی از چهار خال را انتخاب می‌کند و تأیید می‌زند. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. فقط حاکم و فقط در مرحلهٔ انتخاب باید بتواند یک خال معتبر را ثبت کند. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. انتخاب موقت رابط تا زمان تأیید با حکم ثبت‌شدهٔ مسابقه فرق دارد.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
