מדריך ארכיטקטורת תוכנה - שיעור 4 - סידור מקומות לפונקציות
-
סידור מקומות לפונקציות, מחלקות, נושאים, קינון וכדומה. הוא השלב היותר קריטי כדי להפוך את הקוד למסודר.
פונקציה אפילו סטטית, אמורה להיות מקוננת בתוך ההקשר המתאים, ההקשר נקבע לפי נושא הפונקציה ולא מושאה.
למשל כשיש פונקציה שאמורה להחזיר טלפונים של איש קשר, עליה להיות מקוננת בתוך קלאס של איש הקשר, אבל כשיש פונקציה שאמורה להחזיר את כל הפקסים של כל אנשי הקשר לפי תנאי מסויים, היא אמורה להיות מקוננת בתוך קלאס של טלפונים, כאשר הנושא הוא "טלפונים" נחפש את הפונקציה המתאימה בקלאס של טלפונים, ואילו כאשר הנושא הוא "איש קשר" זה הפוך.
אז במקרה דנן יש אובייקט איש קשר, אובייקט טלפון, אוסף אנשי קשר ואוסף טלפונים. כך שכל אובייקט איש קשר אמור להכיל הפניה לרשימה של הטלפונים שלו, וכל אובייקט טלפון אמור להכיל הפניה לאובייקט איש קשר שתחתיו הוא קיים. כאשר נרצה למשל להשתמש באוסף של פקסים, נסנן את הטלפונים לפי "סוג מספר"="פקס" ואם נרצה להוסיף עוד תנאי באנשי הקשר נוסיף כאוות נפשנו, בהנחה שיש לנו הפניה לאיש הקשר.
אם כל פונקציה מסודרת לפי הנושא, אנחנו יכולים להיות בטוחים בדרך שבה נשיג דברים, כלומר זה יחסוך לנו זמן חיפוש כשנרצה לפנות לאוסף כלשהו, נדע את המסלול מראש איך הוא אמור להיות.
עם זאת, יש להפריד בין פונקציות ליבה, לבין פונקציות הצבעה וסדר בלבד. אז מה יהיה הפרוייקט שלנו לשיעור הזה, בואו נלך על תוכנה למשכנתא.
בפרוייקט ייעוץ משכנתאות, אנו צריכים להמליץ ללקוח על משכנתא אופטימלית. משכנתא מורכבת מכמה פרמטרים:
[]סכום נדרש[/]
[]יכולת החזר חודשית[/]
[]שיעור ריבית[/]
[]סוג החישוב (קרן שווה, החזר שווה)[/]
[]סיכונים בריבית משתנה[/]
[]הצמדה למדד[/]
[]ובסופו של דבר תמהיל נכון כי משכנתא בדרך כלל מורכבת מכמה הלוואות.[/]אז ברור שקודם כל יש אובייקט לקוח שמכיל מידע אודות המשכורת של בני הזוג, הסכום הנדרש, ההון העצמי וכו'.
יש את המנועים המרכזיים של המערכת, מה שקרוי בדרך כלל core או קרנל.
נכתוב פונקציה שיודעת לחשב ריבית והצמדה (הפונקציות הפיננסיות המובנות עד כמה שידוע לי יודעות לחשב ריבית בלבד, אולם להצמדה לא מצאתי משהו מוכן) לתקופה כלשהי, הפונקציה תקבל ארגומנט סכום הלוואה, תקופה, מדד צפוי, ושיעור ריבית. פונקציה כזאת אמורה לעבור חודש חודש בלולאה על מנת לתת לנו תוצאה של לוח סילוקין סופי הכולל מדד (אין דרך אחרת לחשב השפעת מדד על הלוואה בהחזר חודשי הואיל והקרן פוחתת בכל חודש).
פונקציה כזאת תהיה בדרך כלל סטטית, הואיל והיא פונקציית ליבה של המערכת, היא עצמאית לחלוטין, ואסור שתהיה מקוננת תחת אובייקט כלשהו.מעבר לכך, יש לנו הצעות מחיר שונות מכמה בנקים, ובכמה סוגי הלוואות, נניח שלכל בנק יש איזה שהוא מחירון בסיסי שהוא נקודת פתיחה למשא ומתן, והדבר תלוי ברמת היציבות של הלווים, איכות הנכס, שיעור ההון העצמי, תקופת ההלוואה, וכן הלאה. את כל הנתונים הללו יש לנו במסד הנתונים.
כעת הזוג שמגיע לבחור משכנתא, אמור להתחיל מנקודה מסויימת, כלומר קודם כל כמה אתם רוצים להחזיר בחודש, מהו הסיכון כאשר ההחזר החודשי עולה עם התקופה, אולי עדיף לקחת חלק מההלוואה לתקופה קצרה יותר וכך עם השנים ילך ההחזר החודשי ויפחת, או יקזז את עליית המדד, וכן הלאה.
נבנה מחלקה שתפקידה הוא "מחולל משכנתאות" שעושה סימולציה של כמה סוגי הלוואות, היא תקבל לתוכה את הנתון של יכולת ההחזר החודשי כנקודת עוגן, ומכאן ואילך תתחיל להציע הלוואות שונות, זה די מסובך לבנות דבר כזה (מה שנקרא באקסל "חתירה למטרה" ורואים על המסך שהוא עושה את זה עם לולאה של ניסיונות), אבל לצורך הענין אני מניח שבנינו מחולל כזה.
אוקי, המחולל הציע לנו מספר תמהילים אפשריים, על בסיס החזר חודשי בין X לבין Y, כל תמהיל הוא אוסף של מספר הלוואות המרכיבות את הסכום הסופי גם יחד. ולכל לקוח יש לנו כמה תמהילים להמליץ ולבחור את האופטימלי מביניהם, לפי פרמטרים של יכולת החזר עלויות סיכון לבנקים ועוד.
כעת אנו צריכים ליצור אופטימייזר שיצביע על כל תמהיל, מהם נקודות החולשה שלו, ומהם נקודות החוזקה שלו. וימליץ ללקוח על התמהיל הכי משתלם, בהתחשב בכך שיש בכל משכנתא מספר מרכיבים בעלי ערך כלכלי ששאיפת הלקוח הוא להפחיתם ככל האפשר, ואולם בדרך כלל הם מקזזים זה את זה.
מרכיב ההחזר החודשי: ככל שהוא נמוך יותר הוא משתלם יותר. מרכיב סך ההחזר: ככל שהסכום שמוחזר לבנק בסך הכל הוא נמוך יותר כך המשכנתא משתלמת יותר. מרכיב הסיכון: ככל שהסיכון לעליית הריבית/מדד הוא נמוך יותר כך הערך הכלכלי של המשכנתא הוא גבוה יותר עבור הלקוח.
אולם, מה נעשה שעל מנת להפחית סיכון של עליית מדד עלינו לשלם ריבית גבוהה יותר, שתשפיע על החזר חודשי גבוה יותר או החזר מוחלט גבוה יותר (פריסת ההלואה לתקופה ארוכה יותר כך שההחזר החודשי יישאר על עמדו ואילו סך ההחזר יעלה), גם בכדי לחשב את הערך הכלכלי הנזגר מכל מרכיב, עלינו לספק לאופטימייזר שלנו נקודות יחס. שאת זה יקבע היועץ, על סמך מידע שיקבל מהלווים, יש כאלו שהסיכון ארוך הטווח חשוב עבורם יותר מאשר החזר חודשי הגבוה בכמה מאות שקלים, ויש כאלו שדווקא ההחזר החודשי הוא נקודת החולשה שלהם, והם מעדיפים אותו נמוך ככל הניתן גם במחיר של סך החזר גבוה.לאחר שפיתחנו את האופטימייזר המשוכלל שלנו, נוכל לתת לו מקום של כבוד באובייקט עצמאי שתפקידו לטפל באופטימיזציה של המשכנתא.
אם נשים לב, כל אובייקט וכל פונקציה היא עולם בפני עצמו, ואין שום טעם לערבב ביניהם, מבחינתי הייתי עושה DLL נפרד לכל פונקציה. נפריד אותם בהפרדה מוחלטת, קבצים נפרדים, מחלקות נפרדות וכולי.
מה שכן, לצורך הסדר הנאות ויכולת השליטה שלנו במערכת, עלינו לסדר תחת כל לקוח, את המחירים המוצעים לו, התמהילים שהמחולל הציע לו, והמלצות האופטימייזר. כל זה גורם לנו להבין שפונקציות ליבה, צריכות להיכתב בנפרד לגמרי מאשר פונקציות של סדר.
הכלל הברור הוא, פונקציה שתפקידה לבצע פעולה מורכבת, עד כמה שניתן לבודד אותה מהמערכת, מומלץ לעשות זאת. וכל הפונקציות האחרות יכולות לשלוח אליה בכיף, אבל היא כשלעצמה צריכה להיות ממוקמת במקום מיוחד שתפקידו לבצע את הפעולה, זוהי בניה מודולרית.
אני מקוה שהמסר הועבר, זהו עיקרון די פשוט אבל חשוב מאוד ברצף המדריכים שלנו.
פורסם במקור בפורום CODE613 ב03/01/2014 00:10 (+02:00)