Title here
Summary here
מערך שיעור: תבניות עיצוב (Design Patterns)
משך: 2 שעות אקדמיות (90 דקות) בכיתה + מצגות סטודנטים בשיעור נפרד/המשך.
מטרת השיעור: הסטודנטים יזהו ששני דפוסים שכבר תרגלו (הנחות, אמצעי תשלום) הם למעשה Strategy Pattern, ויכירו Singleton ו-Factory כתבניות נוספות שכיחות.
בסוף השיעור הסטודנטים צריכים: להסביר מתי להשתמש ב-Strategy/Singleton/Factory, לממש Singleton בטוח (קונסטרוקטור private), ולהכין מצגת קצרה על תבנית עיצוב נוספת לבחירתם.
דגש קריטי: זהו שיעור שמסתיים במטלת הצגה עצמאית (student presentation) — הקדישו את 15 הדקות האחרונות להסבר מפורש על דרישות המצגת והצגת רשימת תבניות מומלצות לבחירה.
מהלך השיעור
| חלק בשיעור | משך | הערות ודגשים |
|---|---|---|
| פתיחה וחיבור | 5 דקות | הזכירו DiscountStrategy/PaymentMethod — “יש לזה שם!” |
| הרעיון: Strategy (שם לדפוס מוכר) | 10 דקות | חיבור ישיר לקוד שכבר נכתב |
| הבעיה + הרעיון: Singleton | 20 דקות | AppConfig — הדגישו קונסטרוקטור private ו-Lazy Init |
| הבעיה + הרעיון: Factory | 20 דקות | NotifierFactory — ריכוז לוגיקת יצירה |
| אזהרה: Over-Engineering | 10 דקות | תבניות הן פתרון לבעיה קונקרטית, לא ברירת מחדל |
| תרגול מודרך | 10 דקות | תרגיל 1+2 |
| הסבר מטלת מצגות | 15 דקות | חלוקת תבניות לבחירה, קריטריונים, מועד הצגה |
דגשים להעברת השיעור
- ההתחלה מ-“אתם כבר עשיתם Strategy בלי לדעת” היא הדרך הכי טובה לפרק את החשש מ"עוד נושא תיאורטי כבד" — תבניות עיצוב הן שם לדבר מוכר, לא כלי חדש.
- Singleton דורש דגש מיוחד על הסכנות שלו (מצב גלובלי, קושי בבדיקות) — לא להציג אותו כ"הכלי הכי טוב תמיד".
- לגבי מטלת המצגות: הכינו מראש רשימת 5-6 תבניות מומלצות (Observer, Decorator, Adapter, Builder, Facade, Command) כדי שסטודנטים לא יתקעו על “איזו תבנית לבחור”.
מושגים
Design Pattern — פתרון מוכר וחוזר לבעיית תכנון נפוצה. Strategy — אלגוריתמים חלופיים מאחורי חוזה משותף. Singleton — מופע יחיד גלובלי, קונסטרוקטור private. Factory — ריכוז לוגיקת יצירת אובייקטים במקום אחד.
תרגיל חשיבה
שאלת פתיחה: “אם Singleton כל כך נוח (גישה גלובלית מכל מקום) — למה לא להשתמש בו לכל מחלקה בתוכנית?”
מהלך: תנו לסטודנטים לחשוב על החיסרון. הובילו לתובנה: גישה גלובלית מכל מקום = תלות נסתרת — קשה לדעת מי משתמש במה, וקשה מאוד להחליף למימוש-בדיקה (Mock) בזמן Unit Testing, כי אין דרך “להזריק” גרסה חלופית כמו שראינו ב-DIP. Singleton שימושי כשבאמת יש צורך במופע יחיד (הגדרות, לוגר) — לא כברירת מחדל נוחה לכל דבר.
מה המרצה מראה בסוף: הראו קוד עם AppConfig.Instance בכמה מקומות שונים בקוד — ואז שאלו “איך הייתם בודקים (Unit Test) פונקציה שמשתמשת ב-AppConfig.Instance, עם ערך שונה מהרגיל?” — הובילו לכך שזה קשה בהרבה מהזרקת Interface (DIP), כהכנה לנושא ה-DAL/DI ביחידת ASP.NET Core הקרובה.