# מערך שיעור: תבניות עיצוב (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 הקרובה.