עליך להתחבר בכדי להוריד קבצים מהאתר
על מנת להבטיח שמשאבינו לא ינוצלו לרעה.
התחברות
הרשמה לאתר
עליך להרשם בכדי להוריד קבצים מהאתר
על מנת להבטיח שמשאבינו לא ינוצלו לרעה.
עדכון פרטים אישיים
תכנות מונחה עצמים (OOP) - דוגמה מסכמת לפולימורפיזם
תכנות מונחה עצמים לא מיועד למערכות קטנות, העוצמה האמיתית והיתרונות הרבים מורגשים בתכנון וכתיבת מערכות תוכנה גדולות.
בדוגמה זו אנסה להביא לידי ביטוי את היתרונות הגלומים בתכנות מונחה עצמים על ידי דוגמה קצת יותר אמיתית ומורכבת.
הדוגמה, אמנם, לא מספיק גדולה ולא מספיק מורכבת, אבל מספיק מקיפה בשביל להתחיל לחוש את אותן היתרונות שדוסקסו במאמרים הקודמים בסדרה.
מאת: ארז קלר
תכנות מונחה עצמים לא מיועד למערכות קטנות, העוצמה האמיתית והיתרונות הרבים מורגשים בתכנון וכתיבת מערכות תוכנה גדולות.
בדוגמה זו אנסה להביא לידי ביטוי את היתרונות הגלומים בתכנות מונחה עצמים על ידי דוגמה קצת יותר אמיתית ומורכבת.
הדוגמה, אמנם, לא מספיק גדולה ולא מספיק מורכבת, אבל מספיק מקיפה בשביל להתחיל לחוש את אותן היתרונות שדוסקסו במאמרים הקודמים בסדרה.
הבעיה:
מפעל זקוק למערכת חישוב שכר חדשה, במפעל (לצורך הדוגמה) יש ארבעה סוגי עובדים:
פועלי יצור המקבלים שכר לפי שעות העבודה שהם עבדו בפועל.
אנשי מכירות - המקבלים שכר חודשי קבוע בתוספת 3% ממחזור המכירות החודשי שלהם.
מנהלים - מקבלים שכר חודשי קבוע.
ומנהלים בכירים - מקבלים שכר חודשי קבוע בתוספת בונוסים שונים.
תכנון ההיררכיה
מניתוח הצרכים עולה מיד הצורך בארבעה מחלקות שונות:
Worker – המחלקה מייצגת פועל ייצור ששכר עבודתו מחושב על פי מכפלת שעות העבודה בשכר לשעה.
Salesman- המחלקה מייצגת איש מכירות שמשכורתו היא תוצאה של מחזור מכירותיו החודשיות.
Manager- המחלקה מייצגת מנהל המקבל משכורת חודשית גלובאלית.
SeniorManager- המחלקה מייצגת מנהל בכיר אשר בנוסף למשכורת החודשית הגלובאלית זכאי לפרמיה מיוחדת.
מתי נלמדים יסודות ההורשה? הם נלמדים כבר בכיתה ד' (או אולי ה') בשיעורי המתמטיקה:
כאשר הוצג בפנינו הביטוי הבא - AB + AC
למדנו לחפש את הגורם המשותף והצבנו אותו מחוץ לסוגריים : (A(B+C.
זה מה שנעשה עכשיו, נחפש את המשותף בין כל המחלקות.
במקרה דנן, כל המחלקות מגדירות את התכונות הפרטיות הבאות :
ID, LastName, FirstName, Address, EmpID, Department.
סביר להניח שבכל אחת מהמחלקות נמצא גם מתודות אשר מטפלות בתכונות הללו,
לדוגמה: יתכן ובכל אחת מהמחלקות נמצא מתודה אשר בודקת את חוקיות ספרת הביקורת של מספר הזהות, ויתכן שבכל אחת מהמחלקות תימצא מתודה הבודקת חוקיות של כתובת וכו' .
הבעיה שצצה היא שכפול קוד, כל אחת מהמחלקות הללו מספקת מימוש עצמאי משלה.
ואולי אין ברירה? הרי רק מתודות של מחלקה יכולות לגשת לתכונות הפרטיות של המחלקה.
הפיתרון טמון בהורשה, ניתן להגדיר מחלקה שתחום אחריותה הוא טיפול בכל אותם תכונות משותפות למחלקות,
המחלקה הנ"ל תרכז את כל התכונות של המחלקה ואת כל המתודות המטפלות בתכונות המשותפות הללו.
שאר המחלקות יירשו את אותה מחלקת הבסיס ובכך יירשו ממנה את כל התכונות וההתנהגויות שהיא מגדירה:
המחלקה Worker יורשת ,כמו שאר חברותיה SalesMan, Manager ו- SeniorManager, את המחלקה Person , משמעות ההורשה שהמחלקה Worker יורשת מהמחלקה Person את כל התכונות והמתודות, המחלקה Worker מכילה, אם כן, שמונה תכונות וכנ"ל שאר חברותיה.
הפעם לא נאלץ לשכפל קוד, המתודה אשר בודקת את חוקיות מספר הזהות של עובד תמצא רק במחלקת הבסיס Person.
ארבעת המחלקות היורשות יוסיפו על התכונות המשותפות שהן מקבלות בירושה ממחלקת הבסיס Person משתנים פרטיים נוספים והתנהגויות ייחודיות להן.
האם סיימנו? האם עומדת מוצגת בפנינו היררכיית מחלקות אופטימאלית?עדיין לא, היררכית המחלקות עדיין אינה מושלמת.
יכולה להיווצר בעיה עם המחלקה Person , יתכן והבעיה אינה עכשווית, יתכן והיא תצוץ בעתיד, אולם כדי לצמצם את כמות השינויים אשר נדרש לבצע (נניח בגרסאות הבאות) כדאי לתת לה מענה כבר עתה.
בעתיד, יתכן ויעלה הצורך להוסיף לאפליקציה יכולת טיפול בלקוחות, לקוח יכול להיות מיוצג באמצעות השדות הבאים : מספר זהות, שם פרטי, שם משפחה, כתובת, סוג לקוח, הזמנות וכו'.
מחלקת לקוח לא תוכל לרשת את המחלקה Person משום שללקוח אין, מן הסתם, מספר עובד, והוא אינו קשור למחלקה מסוימת בחברה.
תכנון נכון של היררכיה מנסה להביא בחשבון גם צרכים עתידיים שעלולים לצוץ, הפיתרון במקרה זה הוא לייצר מחלקת ביניים אשר תכיל את המידע הרלוונטי לכל סוגי העובדים, את EmpID ואת Department .
באופן כללי תמיד רצוי להגדיר מחלקות על פי ההיגיון, על פי צורת החשיבה הטבעית שלנו,
לא לפחד מהרבה מחלקות, עדיפה היררכיה שיש בה הרבה מחלקות קטנות מאשר מעט מחלקות גדולות.
זה מצב עדיף גם מבחינת התחזוקה וגם מבחינת הגמישות של ההיררכיה.
Person נשארת עם מידע מאוד כללי המתאים לכל סוג של אדם.
מהאיור מתברר שהמחלקה Employee יורשת את המחלקה Person שבתורה היא משמשת כמחלקה בסיסית עבור המחלקות Worker, Salesman, Manager, SeniorManager.
ההיררכיה כעת יותר נכונה אולם עדיין לא מושלמת.
כאשר נבחן את המחלקות SeniorManager ו- Manager נזהה שבשניהן מוגדר משתנה פרטי המייצג את גובה השכר החודשי , סביר להניח אם כן שבשניהן מוגדרות מתודות אשר מטפלות במשכורת של מנהלים אלו.
המחלקה SeniorManager מכילה נתון נוסף המייצג את גובה הבונוס לו זכאי המנהל הבכיר.
אם כן, יש מקום שהמחלקה SeniorManager תירש את המחלקה Manager , המשמעות היא ש- SeniorManager מקבלת כחלק מהירושה את היכולת לטפל משכורת חודשית ומוסיפה עליה את ניהול הבונוסים על מנת לחשב את משכורתו של המנהל הבכיר.
הפעם התמונה יותר מושלמת :
כל המחלקות בהיררכיה עונות על התנאי “IS A”:
| Employee “Is a” Person Worker “Is a” Employee SeniorManager “is a” Manager |
באמצעות שאלה זו “Is a” נזהה ונמפה את יחסי ההורשה בהיררכיה, במקרה ושתי מחלקות אינן עונות בחיוב על תנאי זה, אין שום היגיון בהגדרת יחסי הורשה ביניהן.
כל הזכויות שמורות למחבר ©