התייעצות בDESIGN

[johnyG]

התייעצות בDESIGN

יש לי מחלקה הנקראת JOB. היא מייצגת עבודה/משימה מהעולם האמיתי - משימה שמפעל צריך לבצע. לדוגמא היא כוללת את התאריך האחרון לביצוע ומידע נוסף. יש לי דרישה לבצע פעולה מסוג ROUTING. פעולה זו למעשה קובעת כיצד תתפצל המשימה בין מפעלים שונים. מבחינת תוכנה, הפעולה הזאת בסה"כ תשנה ערכים של תכונות בתוך ג'וב. אולם פעולה זו מורכבת והיא משתמש במאשבים חיצונים לקבלת החלטות (קבצי EXCEL למשל). יש לי דילמה בDESIGN ואשמח לשמוע דיעות בנושא. אפשרות א': אני יוצר SERVICE (מחלקה עם פעולות בלבד) עם פעולה ROUTEJOB (המקבלת כפרמטר מופע של ג'וב). יוצר ממשק להגדרת פעולת ראוטינג IROUTINGPROVIDER, הממשק מחייב מתודה אחת: routeJob המתודה מקבלת ג'וב כפרמטר ומשנה את הערכים. יוצר מימושים של הממשק הנ"ל (אחד אמיתי, אחד לטסטים). ואז פשוט הסרוויס מאתחל מופע כלשהו של IROUTINGPROVIDER מעביר לו הג'וב. באפשרות הזאת ה-IROUTINGPROVIDER אחראי לבדו לביצוע פעולות הראוטינג והוא משנה ערכים בתוך ג'וב. יתרון: מודול גדול שמקבל החלטה עם משאבים חיצוניים מופרד לממשק נוסף ותחום, היישות לא צריכה להתעסק בלוגיקה המסובכת הזאת חיסרון: אין אפשרות לעשות ראוטינג לפי סוגים שונים של ג'וב. מודול חיצוני משנה את היישויות ולא מאפשר ליישויות לתקשר בינהן. אפשרות ב': הג'וב עצמו מממש מתודה ROUTE והג'וב עצמו אחראי לפעולת הראוטינג. הוא אולי ישתמש בעצמו בROUTING PROVIDER ואולי לא - כל מימוש של ג'וב יכול לעשות ראוטינג איך שבא לו. יתרון: הג'וב עצמו מחליט איך להתנהג, מאפשר הורשה של ג'ובים שונים שיעשו ראוטיג בצורה שונה. חיסרון: הג'וב שהוא בסה"כ ישות מיישם מודול גדול מאוד של החלטה שצריכה להשתמש במשאבים חיצוניים (אקסל). דעתכם?

 

[arnonrgo]

Domain Driven Design

אין כאן מספיק מידע כדי לתת תשובה מוחלטת אבל באופן עקרוני אפשרות ב נשמעת כיוון הרבה יותר מוצלח Swiss army knife שמקבל את כל ההחלטות לא נשמע אופציה מוצלחת - מה שיצא לך מזה זה הרבה מאד ifים ובסיס קוד לא נוח לגבי השאלה האם הJobים צריכים לקבל את ההחלטה או רכיבים חיצוניים תלויה המהות של ההחלטה - שוב, באופן עקרוני, נשמע שהJob כן יכול לעשות זאת אם כי הוא כנראה צריך תלויות ברכיבים חיצוניים (resources ?) שאותם הJob יכול לקבל עם שימוש בDependency Injection ע"י מה שיוצר את הJob כדאי לך לקרוא קצת על Domain Driven Design (http://domaindrivendesign.org/books/index.html אני משער שאח"כ לא תגיד דברים כמו "שהוא בסה"כ ישות" ארנון

 

[johnyG]

המשך הדיון

הי ארנון, תודה על התשובה. יש לי היכרות סבירה עם DDD, אך היא לא עוזרת לי בהתלבטות. הכוונה במשפט "בסה"כ יישות" היא שאם ג'וב יתעסק עם החלטות ראוטינג מורכבות הקשורות גם ברכיבים חיצוניים כמו קבצי אקסל, זה יפגע למדי בCOHESIVENESS שלו. ג'וב אמור לתאר התנהגות ומידע של עבודה. לא נשמע לי אסתטי לתת לג'וב לגשת לROUTING PROVIDER בעצמו. חשבתי על הפיתרון הבא: ROUTING SERVICE - מקבל את הבקשה לביצוע ראוטינג ROUTING DECISION - מחלקת מידע המתארת את החלטת הראוטינג IROUTING PROVIDER - אחראי על הנפקת ROUTING DECISION JOB - אחראי על סידור ROUTING DECISION בתוך עצמו כך ש: ROUTING SERVICE מקבל בקשה לניתוב, מאתחל IROUTING PROVIDER (בעזרת IOC למשל) האחרון מחזיר ROUTING DECISION ואז קוראים למתודה של ג'וב לרואטינג שמקבלת כבר את ההחלטה ורק עושה את סידור המידע בתוך עצמה בלבד. מצורפות דיאגרמות. אשמח לדיעות. נ.ב. ארנון, אני קורא הדוק של הבלוג שלך.

 

[arnonrgo]

מהות הJob

ני לא מכיר את הdomain שלך כך שיכול להיות שאני מדבר שטויות אבל ההתרשמות שלי היא שJob לא מבצע את העבודה עצמה אלא הוא הוא הrouting זאת אומרת הוא מבטא את העובדה שמשהו אמור להבצע במקומות מסוימים תחת ההנחה הזו הגיוני שבהנתן resource providers ששולטים על הסטאטוס (יכולות , זמינות וכו) של כל משאב חיצוני לתת לjob להחליט אם ישנם אילוצים שמחוץ לscope של הידע של הJob הייתי נוצן לJob להמליץ על resources שמסוגלים לבצע את הjob ואז לתת לגורם חיצוני נוסף לקבל את ההחלטה הסופית ל סמך ההמלצות (הJob בעצם אומר מה סט היכולות הנדרשות לביצוע הjob ואז השידוך הוא החלטה חיצונית) > נ.ב. ארנון, אני קורא אדוק של הבלוג שלך. אה - זה אתה בכל מקרה תודה ארנון

 

[ייוניי]

אני חושב ש JOB צריך לעשות יותר עבודה

אין ספק שעל מנת לבצע את העבודה דרושים לו אובייקטים נוספים שאליהם יעביר את עניין קבלת ההחלטות הרלוונטיות אבל ה"מניע" של התהליך צריך להיות JOB מפני שהמידע הדרוש להנעת התהליך נמצא בו. אפשר לומר שיש כאן עוד דוגמא ל IoC מפני שבמקום לתחקר את אובייקט ה JOB מבחוץ, לקבל החלטות ולעדכן את האובייקט אתה יכול להעביר לו את השליטה ולספק לו אובייקטים נוספים שאליהם יקרא על מנת להתמודד עם החלטות הראוטינג המורכבות הקשורות גם ברכיבים חיצוניים. זה בעצם לא רחוק מהתרשים שצירפת רק שגם את הלולאה הייתי מכניס לתוך מתודה ב JOB שתקבל את ה RoutingProvider.

 

[johnyG]

תודה