مسئله‌ای که باید حل می‌کردم
خاموش‌کردن ظاهر کارت غیرمجاز کافی نیست. اگر کنترلر یا ربات مستقیم حرکت ارسال کنه، قانون باید باز هم اجبار به خال را بررسی کنه و پاسخ مشخص بدهد.
پیاده‌سازی در نسخهٔ فعلی
HokmLegalCardValidator.GetLegalCards وقتی خال آغاز وجود نداره همهٔ کارت‌ها را می‌دهد؛ اگر دست آن خال را داره فقط همان خال مجاز هست. ValidateCardPlay مالکیت، تکرار صندلی و کامل‌نبودن دور را هم بررسی می‌کنه.
تصمیم و هزینهٔ طراحی
خروجی مجموعهٔ کارت‌های مجاز را همراه وضعیت اعتبار داره. همین تصمیم را می‌شود برای روشنایی کارت در رابط و انتخاب ربات استفاده کرد، بدون دو نسخهٔ مستقل از قانون.
مرزهای فعلی
این اعتبارسنج وضعیت دست و دور را می‌گیرد و خودش مدیر نوبت نیست. چک مالک نوبت باید در مسیر اجرای حرکت هم باقی بماند؛ رابط درست جای آن کنترل را نمی‌گیرد.
فهرست مجاز، مجوز اجرای کامل نیست
اگر خال آغاز دور دل باشد و بازیکن هنوز دل داشته باشد، GetLegalCards فقط دل‌های دست را برمی‌گرداند. اگر دل نداشته باشد، همهٔ کارت‌های غیر null دست در فهرست قرار می‌گیرندد. این دو حالت به رابط امکان می‌دهند محدودیت پیروی از خال را توضیح دهد. اما متد فهرست‌ساز به‌تنهایی کامل بودن دور یا بازی قبلی همان صندلی را رد نمی‌کنه؛ این بررسی‌ها در ValidateCardPlay انجام می‌شوند. بنابراین فهرست مناسب برای روشن کردن کارت‌ها نباید به اشتباه یک مجوز دائمی برای حرکت، بدون بررسی دوبارهٔ وضعیت، تلقی بشه.
اعتبارسنجی کارت انتخابی پیش از قبول، نبودن کارت، مشخصات نامناسب، کامل بودن دور، بازی دوبارهٔ صندلی و نبودن کارت در دست را بررسی می‌کنه. HandContainsCard تطبیق را با ReferenceEquals یا InstanceId انجام می‌دهد؛ دو کارت صرفاً با خال و رتبهٔ مشابه معادل فرض نمی‌شوند. این تصمیم با هویت اجرایی کارت هماهنگ هست. در حالت رد شدن نیز نتیجه می‌تواند فهرست legalCards را حمل کنه تا مصرف‌کننده دلیل و گزینه‌های موجود را با هم داشته باشد. داشتن این داده مفید هست، اما ترجمهٔ پیام و شکل نمایش خطا وظیفهٔ همین validator نیست.
در خواندن دقیق کد، AddAllCards فقط null را فیلتر می‌کنه و اعتبار کارت استاندارد در مرحلهٔ ValidateCardPlay جدا بررسی می‌شود. پس اگر دادهٔ دست خراب باشد، نباید فرض کرد نام GetLegalCards تضمین کرده هر عضو آن از همهٔ بررسی‌ها عبور می‌کنه. همچنین validator نمی‌داند اکنون نوبت کدوم RuntimePlayer هست. در دلو مرز مسئولیت باید روشن بماند: پیروی از خال و مالکیت در این سرویس، نوبت در مسیر اجرای حرکت. ترکیب این پاسخ‌ها به رفتار صحیح منجر می‌شود؛ تکیه بر ظاهر روشن یک کارت، بررسی کامل سمت منطق را حذف نمی‌کنه.
چیزی که از این مرحله یاد گرفتم
برای من، بازخورد غیرمجاز باید از همان حقیقتی بیاید که بازی از آن استفاده می‌کنه. بازیکن نباید کارتی را قابل بازی ببیند که لحظهٔ اجرا با یک قانون متفاوت رد می‌شود.
مثال عملی اجبار به خال در حکم
برای فهم عملی اجبار به خال در حکم، یک مثال آموزشی را قدم‌به‌قدم دنبال کنیم. بازیکن در دستش دل دارد و دور با دل شروع شده؛ انتخاب پیک باید رد شود. پیش از اجرا، وضعیت آغاز را روی کاغذ بنویس؛ مشخص کن چه چیزی می‌تواند تغییر کند و چه چیزی باید ثابت بماند. بعد فقط همین مسیر را اجرا کن. این مثال گزارشی از آمار کاربران یا قابلیت تازهٔ منتشرشدهٔ دلو نیست؛ تمرینی برای روشن کردن تصمیم طراحی همین مطلب است.
خطای رایج و علت آن
کم‌رنگ کردن کارت در رابط کافی نیست اگر منطق هنوز حرکت غیرمجاز را بپذیرد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. بازیکن انسانی و ربات باید از یک مرجع برای تشخیص حرکت مجاز استفاده کنند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
هم رابط و هم قانون را با داشتن خال، نداشتن خال و دست خالی آزمایش کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | بازیکن در دستش دل دارد و دور با دل شروع شده؛ انتخاب پیک باید رد شود. |
| ریسک اصلی | کم‌رنگ کردن کارت در رابط کافی نیست اگر منطق هنوز حرکت غیرمجاز را بپذیرد. |
| روش بررسی | هم رابط و هم قانون را با داشتن خال، نداشتن خال و دست خالی آزمایش کن. |
| مرز نتیجه‌گیری | بازیکن انسانی و ربات باید از یک مرجع برای تشخیص حرکت مجاز استفاده کنند. |
پرسش‌های کاربردی دربارهٔ اجبار به خال در حکم
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: بازیکن در دستش دل دارد و دور با دل شروع شده؛ انتخاب پیک باید رد شود. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. هم رابط و هم قانون را با داشتن خال، نداشتن خال و دست خالی آزمایش کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. بازیکن انسانی و ربات باید از یک مرجع برای تشخیص حرکت مجاز استفاده کنند.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
