מערך שיעור: תכנון OOP ותרגול משלב

משך: יום לימוד מלא — 6 שעות אקדמיות (270 דקות).

מטרת השיעור: להעביר את הסטודנטים מ"לדעת לכתוב Class" ל"לדעת לתכנן מערכת של Classes": לקבל דרישה מילולית ולהפוך אותה למבנה סביר ומנומק.

בסוף השיעור הסטודנטים צריכים:

1. לחלץ מדרישה מילולית Classes, Attributes ו-Methods, ולנמק כל החלטה (ארבע השאלות, Information Expert).
2. לזהות God Class ולפרק אותה לפי SRP, ולבחור נכון בין Composition ל-Inheritance (has-a מול is-a).
3. לאבחן באגים טיפוסיים של OOP, ולבצע Refactoring מקוד פרוצדורלי ל-OOP בצעדים בטוחים.

דגש קריטי: זה היום הכי חשוב בשבוע (כך מוגדר בסילבוס). הדגש הוא על חשיבה, ולא על תחביר. המרצה צריך לחשוב בקול, להציג התלבטויות (“אולי לקוח הוא רק Attribute? בואו נבדוק…”), ולהראות שאין תמיד תשובה אחת נכונה, אבל יש תשובות מנומקות.

מהלך השיעור#

דגשים להעברת השיעור#

• אין “פתרון בית ספר” אחד. כשסטודנט מציע תכנון אחר, לשאול “מה היתרון? מה החיסרון? מה קורה כשהדרישה משתנה?” במקום “לא נכון”.
• “הדרישה משתנה” הוא הכלי הדידקטי החזק ביותר היום. לכל תכנון, להוסיף דרישה (מועדון לקוחות, הקפאת מנוי, סוג חדש) ולבדוק כמה קוד צריך לשנות. כך מבינים למה תכנון טוב.
• ארבע השאלות ו-Information Expert — לכתוב אותן על לוח צדדי שנשאר כל היום, ולחזור אליהן בכל החלטה.
• Composition over Inheritance — הדוגמה החזקה היא שדרוג מנוי (Plan). לשאול: “איך משדרגים מנוי כשהסוג נקבע בירושה?”
• “פעולה שהיא דבר” (Loan, Booking, Ride) היא תובנה לא אינטואיטיבית. להדגיש אותה במפורש.
• Refactoring: להריץ מול הכיתה אחרי כל צעד, גם כשזה נראה מיותר. ההרגל הוא המסר.
• הכנה ליום הפרויקט: לסיים בהודעה: “ביום הפרויקט בונים פרויקט שלם, ושעה ראשונה היא רק תכנון, בלי מחשב.”

מושגים#

תרגיל חשיבה#

שאלת פתיחה (תחילת הסדנה): “אתם מקבלים את הדרישה של KodFit. יש לכם 10 דקות, בלי מחשב. תכתבו על דף אילו Classes תהיו, ומה כל אחת עושה במשפט.”

מהלך:

1. כל זוג כותב תכנון. המרצה אוסף 3–4 תכנונים שונים על הלוח.
2. דיון על הנקודות שבהן התכנונים נבדלים:
   • “סוג מנוי, Attribute (plan = "basic") או היררכיה?” → לשאול: “מה קורה כשמוסיפים Student?”
   • “PremiumMember יורש מ-Member?” → לשאול: “מה קורה כשדנה משדרגת?”
   • “מי בודק אם יש מקום בשיעור?” → Information Expert.
   • “צריך Class להרשמה?” → “יש לה נתונים משלה? בדרישה הנוכחית, לא. אם יוסיפו ‘הרשמה עם תאריך ונוכחות’, כן.”
3. מתכנסים יחד לתכנון אחד מנומק.

מה המרצה מראה בסוף: את התרשים הסופי (Gym, Member, Plan-hierarchy, GymClass) עם חצים מסומנים has-a / is-a, ומתחתיו את טבלת “דרישה → Class.Method”, שמראה שכל שורה בדרישה מצאה בית. ואז להוסיף בלייב את הדרישה החדשה (הקפאה + Student), ולהראות שהשינוי נוגע ב-2 מקומות קטנים בלבד. משפט סיום: “תכנון טוב נבחן לא כשכותבים אותו, אלא כשמשנים אותו.”