מערך שיעור: Class, Object ו-Instance
משך: יום לימוד מלא — 6 שעות אקדמיות (270 דקות).
מטרת השיעור: הסטודנטים יבינו למה OOP קיים (לפני איך), ויבנו מודל מנטלי יציב של Class כתבנית, Object כמופע, ו-self כ"האובייקט הזה".
בסוף השיעור הסטודנטים צריכים:
- להסביר באנלוגיה משלהם את ההבדל בין Class ל-Object, ולזהות את הבעיות של קוד פרוצדורלי שמצדיקות OOP.
- לכתוב Class עם
__init__, Instance Attributes, ולידציה בסיסית, ומתודות (Getter ו-Setter). - להסביר שלב אחר שלב מה קורה ב-
obj = Class(args)וב-obj.method(x), כולל מאיפה מגיעself.
דגש קריטי: לא למהר. זה השבוע החשוב בקורס. עדיף שכל הכיתה תבין לעומק את self ואת __init__ מאשר להגיע למתודות מתקדמות. self הוא נקודת התקיעה הגדולה, ולכן להקדיש לו זמן, ציורים וחזרות.
מהלך השיעור
| חלק בשיעור | משך | הערות ודגשים |
|---|---|---|
| למה OOP? | 45 דק' | לכתוב יחד את מערכת הבנק הפרוצדורלית, ואז “לשבור” אותה (balance שלילי, שגיאת כתיב, סוג חשבון חדש). רק אחרי זה, הרעיון. |
| Class ו-Object | 35 דק' | Class ריקה, יצירת אובייקטים, type, is. הוספת Attributes מבחוץ, והבעיה שזה יוצר. |
| הפסקה | 15 דק' | |
__init__ ו-self | 55 דק' | אנלוגיית טופס ההרשמה. לכתוב על הלוח את 5 השלבים של Student("Dana", 24). Student, Product, Person. |
Methods ו-__str__ | 50 דק' | obj.m(x) ≡ Class.m(obj, x) על הלוח. BankAccount מלא, “המערכת מהבוקר, פתורה”. |
| הפסקה | 15 דק' | |
| תרגול + Mini Project | 45 דק' | מערכת מלאי. לעבור ולבדוק שכולם משתמשים ב-self. נכון. |
| בדוק את עצמך | 10 דק' |
דגשים להעברת השיעור
- “למה” לפני “איך”. לא לכתוב
classלפני שהסטודנטים הרגישו את הבעיה בקוד פרוצדורלי. זה עיקרון ה-Self-Learning של כל הקורס. - אנלוגיה אחת עקבית: תבנית ייצור מכוניות (Class) מול מכונית ספציפית (Object). לחזור אליה לאורך כל השבוע.
selfבציור: לצייר את ה-Class כ"תבנית" אחת, ושלושה אובייקטים. כשקוראיםdana.add_grade(90), לצייר חץ מ-selfאל האובייקט של דנה. לחזור על זה עם אבי.- להראות את מה ש-Python עושה בפועל: להריץ מול הכיתה
Student.add_grade(dana, 90). זה עובד, וזה “מסיר את הקסם” מ-self. - שגיאות ההודעה “takes 2 positional arguments but 3 were given” — להפיק אותה בכוונה ולפענח יחד. כל סטודנט ייתקל בה השבוע.
- לא להכניס עדיין Class Attributes, Encapsulation או Inheritance. אם נשאלים, “מחר” / “בנושא ירושה ופולימורפיזם”.
- Dunder methods: להציג רק
__init__ו-__str__. לא להיכנס ל-__repr__ושאר הקסמים.
מושגים
| מושג | הסבר קצר |
|---|---|
| OOP | תכנות שמארגן קוד סביב אובייקטים: נתונים + פעולות. |
| Procedural Programming | נתונים ופונקציות בנפרד. |
| Class | תבנית שמגדירה סוג חדש. שם ב-PascalCase. |
| Object / Instance | דבר ספציפי שנוצר מ-Class. |
| Instantiation | יצירת Object מ-Class: Class(). |
| Attribute | נתון ששייך לאובייקט: obj.name. |
| Instance Attribute | Attribute שמוגדר עם self.x ושונה בכל אובייקט. |
__init__ / Constructor | מתודה שרצה אוטומטית ביצירה ומאתחלת את האובייקט. |
self | האובייקט הנוכחי. פרמטר ראשון בכל מתודה, ו-Python מעבירה אותו. |
| Method | פונקציה בתוך Class שפועלת על האובייקט. |
| State | ערכי ה-Attributes של אובייקט ברגע נתון. |
| Getter / Setter | מתודה שמחזירה ערך / מתודה שמשנה מצב. |
Dunder / __str__ | מתודה מיוחדת עם __ / ייצוג טקסטואלי ל-print. |
תרגיל חשיבה
שאלת פתיחה (תחילת היום, לפני כל קוד): “אתם צריכים לכתוב מערכת לניהול חשבונות בנק ל-10,000 לקוחות. ביום הראשון יש רק הפקדה ומשיכה. בחודש הבא מוסיפים חשבון חיסכון עם ריבית. בעוד חצי שנה, חשבון עסקי עם מסגרת אשראי. איך תארגנו את הקוד כך שלא יהפוך לסלט?”
מהלך:
- לתת לכיתה 5 דקות לתכנן בזוגות בלי OOP: dicts ופונקציות.
- לאסוף תכנונים. לשאול: “מה מונע מקוד אחר לשנות balance ישירות? איפה רשום מה ‘חייב’ להיות בחשבון? מה קורה ל-
withdrawכשמגיע סוג חשבון שלישי ורביעי?” - לכתוב יחד את הגרסה הפרוצדורלית, ולשבור אותה ב-3 דרכים מול הכיתה.
- רק אז להציג את הרעיון: “מה אם החשבון עצמו היה יודע מה מותר לו?”
מה המרצה מראה בסוף: את אותה מערכת כ-BankAccount (משיעור המתודות), זו לצד זו עם הגרסה הפרוצדורלית, ולסמן בצבע: נתונים (Attributes), כללים (בדיקות בתוך המתודות), פעולות (Methods). ולהשאיר על הלוח את המשפט: “Object = נתונים + ההתנהגות שמגינה עליהם.” (בנושא ירושה ופולימורפיזם לחזור לשאלה של חשבון החיסכון, כשמגיעים ל-Inheritance.)