Use case מהלך בודד בשח

[צונאמי]

יותר נכון להגיד

אני לא רוצה שיהיה אפשר לעשות PICKUP לכלי EMPTY. את הפעולה MOVE_TO יהיה אפשר לעשות רק אם הכלי במצב מורם מהלוח.

 

[Gaus]

OK ברור, זה עניין של גישה.. ../images/Emo45.gif

 

[צונאמי]

המממ...צודק ...לא הלכתי על מספר

משחקים סימולטניים. אבל לא אמורה להיות בעיה להשאיר את זה ככה ולשנות במידת הצורך. אפשר לכתוב עבור כלי מתודה שמחזירה ה- OWNER BOARD שלו. (ולשנות את המימוש שיהיה צורך - אם בכלל)

 

[ייוניי]

יש מקום לשחקן

שתפקידו לבקש מהמשתמש את המהלך הבא. אני רואה שני מופעים שלו במחלקת ה"משחק" (לשני השחקנים במשחק) ומתודת "בקש מהלך" שתחזיר אובייקט "מהלך" או משהו בסגנון.

 

[Gaus]

זה בדיוק מה שהתכוונתי!

חשבתי מי זה האובייקט שייצר מבקש מהלך את המופע, ישנה אפשרות שזה יהיה שחקן, או אולי הכלי שאותו השחקן בוחר לבצע עימו מהלך.. דעתך..

 

[ייוניי]

האמת היא

שזה נראה לי סוג של State Pattern שבו בכל מקרה יש לך בכל רגע נתון שחקן פעיל ושחקן ממתין. אין שום בעיה שמתודת "בקש מהלך" של השחקן לא תבקש ממנו מהלך אלא תעביר לכל הכלים של אותו שחקן פקודה להפוך לפעילים (ואת של היריב לא פעילים) ולהמתין לבקשות תזוזה מהמשתמש (לא מה"שחקן"!). ואז רק אחרי שהמשתמש מנסה להרים כלי ולזרוק אותו למשבצת אחרת יווצר אובייקט ה"מהלך" וישלח ללוח להמשך טיפול.

 

[עידו פ]

דווקא המילה "שחקן" די מתאימה מאחר

ומבחינת ה-UC (קיצור של UseCase) השחקן ב-UC (מה שמכונה Actor) הוא השחקן שמשחק את המשחק (ה-Player). ובשביל להבהיר את עצמי: UC מורכב משחקן שיוזם את הפעולה (לא שחקן במובן של לוח שחמט אלא שחקן במובן של תפקיד כלשהו במערכת המחשב), מהפעולה עצמה ובמידת הצורך - משחקן שנהנה מהפעולה (נהנה = מקבל פידבק / תגובה / פלט) מאחר והזזה של כלי מבוצעת ע"י השחקן (ה-player) ומאחר ובהעדר שם אחר המתאר את המשתמש ואת תפקידו במערכת, השחקן ב-UC (ה-Actor) מכונה "שחקן" (Player). מה שצריך לקחת מכל הבבלת הנ"ל זה את הסיכום הבא: שחקן ב-UC (היינו Actor) אינו חייב להיות מיוצג במערכת באמצעות מחלקה ולכן, בהקשר לשאלתך - אין צורך במחלקת "שחקן", אלא אם כן ישנם פרטים מיוחדים שהיית רוצה לשמור עליו (השם שלו, הסטוריית המשחקים שלו, צבע כלים מועדף וכו').

 

[Gaus]

כן, ישנה כוונה עתידית כזו..

..לשמור פרטים , לבצע דירוגים וכדומה.. אך זה לא רלוונטי כרגע, מכיוון שזה לר בסקופ של הUC הנ"ל, כך שלא צריך להכנס לזה.. בנוגע לUC, מי לדעתך הACTOR של הפעולה זהו.. לא ממש הבנתי... היתכן שהACTOR לא מיוצג בתור אובייקט?.. הסברים..?.. אם רובכם מחזיקים בדעה שאין צורך בשחקן, אשקול זאת שוב.. רק , אם אין שחקן, איך אני יוצר מכנה משותף מרכז לכלים מאותו צבע? הם צריכים להיות משויכים למאפיין (קבוצה) מסוים, שהפעולה הסופית הינה פעולה שלו, ולא של הכלי, הכלי הוא רק תוצאת המהלך.. לא?... הגישה שלכם מעניינת, ואשמח אם תפרטו אותה יותר, בצורה טיפה יותר עמוקה, בשלבים (צעד אחר צעד), מהם הצעדים של הUC הנ"ל, אין מנוס מזה שאאמץ את הגישה שלכם, ולו רק מכיוון שהיא מאוד מעניינת אותי, ומשנה לי את צורת החשיבה... אולי אני קצת מיושן בגישה שלי.. תודה.

 

[arn0n]

לא נותר לי הרבה להוסיף...

אחרי כל מה שנאמר כאן... אז רק לגבי שיוך הכלים לשחקן - זהו ה-ATTRIBUTE של הצבע שמשויך לכל כלי. אני בכוונה מנסה להיות מינימליסט - אם אפשר בלי לייצג שחקן בקוד, אז יופי (ובאמת, ה-UC הספציפי הזה מאפשר להמנע מכך). עוד משהו - אני מסכים עם ההחלטה שלך להתמקד בממשק COMMAND LINE בינתיים. לדעתי זאת הדרך הטובה ביותר להתקדם כרגע - לבנות את המערכת בפטרן MVC, כאשר החלק של ה-VC הוא כרגע הכי פשוט שאפשר (COMMAND LINE), ואח"כ אפשר יהיה להוסיף ממשק GUI, WEB, או IVR...

 

[Gaus]

../images/Emo45.gif

 

[עידו פ]

תיאור יפה של UC, רק כמה הערות אם

יורשה לי: תיאור סטנדרטי של UC אמור להכיל את הרכיבים הבאים: 1. תיאור ה-flow הרגיל של ה-UC (מה שמכונה happy flow) 2. תיאור חריגות מה-flow הרגיל 3. הסברים נוספים שלא אכנס אליהם כרגע כי אני רוצה להתמקד בשני התיאורים הנ"ל (אבל בגדול מדובר על תיאור ה-UC שמבצעים extends/includes ל-UC זה ותיאורים נוספים לגבי מצבי התחל וסוף של המערכת) לגבי שני הסעיפים הראשונים, ה-UC יראה יותר טוב באופן הבא (הרשתי לעצמי לעתיק את המלל שכתבת, בערך מילה במילה): 1. השחקן בוחר את הכלי אותו הוא רוצה להזיז 2. המערכת מסמנת על הלוח את הכלי 3. השחקן בוחר לאן ברצונו להזיז את הכלי 4. המערכת מוודאת שהמהלך תקין (אם המהלך לא תקין - ראה סעיף א') 5. המערכת מוודאת שהמהלך חוקי (אם המהלך לא חוקי - ראה סעיף ב') 6. המערכת מעדכנת את מיקום הכלי על הלוח (אם נוצר מט - ראה סעיף ג', אם נפל כלי - ראה סעיף ד', אם נפל המלך - ראה סעיף ה' ...) 7. סוף ה-UC סעיף א' 1. המערכת מודיעה לשחקן שהמהלך לא תקין 2. המערכת מסירה את הסימון מהכלי על הלוח 3. חזרה לסעיף 7 במסלול המקורי סעיף ב' 1. המערכת מודיעה לשחקן מדוע המהלך אינו חוקי 2. המערכת מסירה את הסימון מהכלי על הלוח 3. חזרה לסעיף 7 במסלול המקורי ... (וכן הלאה עם הסעיפים) מבחינת ה-UC צריכים להיות מתוארים המסלול הרגיל והמסלולים המיוחדים, שאח"כ מתורגמים בזמן העיצוב להרבה IF-ELSE. שים לב שהאפיון גם לא מגדיר בשלב זה ויזואליות (לא רשמתי מה זה אומר "סימון הכלי" - אולי זה סימון ריבוע מסביב לציור, ואולי סתם לרשום בצד שהכלי סומן), אלא אם כן יש עיצוב של המסך ואז אפשר לציין זאת (אם רוצים). דרך אחרת לעשות את התיעוד הנ"ל היא באמצעות טבלה עם שתי עמודות המציינת בעמודה אחת את פעולת השחקן (ה-actor) ובעמודה השנייה את תגובה המערכת (ה-system)

 

[Gaus]

כשאתה מציין מערכת...

זה בעצם ישות נפרדת? מעין מנהל משחק כללי?

 

[עידו פ]

מערכת = הלוגיקה של המערכת

הלוגיקה זה אותם שורות קוד שיש במחלקות השונות שביחד אחראיות על אכיפת החוקים של משחק השח-מט.

 

[Gaus]

o.k ברור... ../images/Emo51.gif

רק רציתי שזה יהיה וודאי לי... אגב, כל הכבוד על ההשקעה, מאוד מעניין.. את חוקי הUC אני מכיר, ואם אתה רוצה יש לי מצגת נחמדה שמסבירה את מבנה UC תהליך יצירב ועוד..

 

[צונאמי]

גאוס - יש התקדמות ? החלטות ?

לי אישית נשמע אחלה פרוייקט ללמוד ממנו ואשמח להיות מעורב בהמשך

 

[Gaus]

קודם תודה צונאמי... ו..

כן, בהחלט זה אחלה משהן ללמוד ממנו, בגלל זה בחרתי את זה.. לשאלתך, וכאן אני גם מבקש כמובן את רשותך, לקחתי באמת לעומק תשומת ליבי את ההערות שלכם כאן, וגם הורדתי לקבצים אצלי את העבודה היפה שאתה עשית... ביומיים האחרונים הייתי טרוד בלסיים איזו מערכת בדוט.נט כך שלצערי לא יצא לי ממש לקדם את הנושא, אך עד סוף היום אני מקווה שאוכל להלועת אליכן את התוצר הראשוני, מקווה כולל קוד... תודה והמשך יומ'טוב. גאוס. אגב, צונאמי, אני באמת מודה לך, ואשמח לגמול לך בעתיד..