Until The Next Exception

  MVVM - מבוא תבנית מבנה לעיצוב תוכנה, מחליפה את טכנולוגיות העיצוב MVC  ו MVP פופולרית בעיקר בפיתוח לסביבת XAML WPF  הבנת התבנית ואני מדגיש "הבנת" דורשת ידע מוקדם בDesign Patterns  אותם הצגתי בפוסטים הקודמים.  עקרונות: ניצור הפרדה מלאה וחוסר תלות בין הVIEW   לבין הCode behind שהיינו רגילים לראות באפליקציית חלונות, עכשיו אותו קוד ייקרא ViewModel דהיינו המודל של התצוגה, בנוסף ישנו תמיד ה"מודל" האמיתי  (Person, Car, Animal, Customer) שאותו נציג בView. הרווח הוא תחזוקה , בדיקות, שינויים, שימוש חוזר ועוד. אני לא אאריך על מהות הMVVM  כי יש המון ידע ברשת איך לממש ומה זה אומר. (גם בעברית) טכניקה:  שימוש בBinding  - לסנכרן מידע מהViewModel  ל View ולא עוד קשר ישיר.              שימוש...

Observer Pattern  תבנית הobserver היא אחת הנפוצות ביותר מכל תבניות העיצוב בכלל. ובתכנות מונחה עצמים בפרט. עצמים=קלאסים, נרצה לדעת כשאובייקט משנה סטייט ולהגיב בהתאם. מה המוטיבציה? כהסבר ראשוני נניח שאובייקט A  רוצה לדעת כשאובייקט B משנה סטטוס, אבל לA  אין גישה לB !! ז"א A הוא אובייקט עצמאי , וגם B.. אני צריך דרך ליידע את A  שנעשה שינוי אצל B.. ואני לא מתכוון להריץ טיימר שבכל חלקיק שניה יבדוק מה מצבם של האובייקטים במערכת, (תנסו, תספרו אח"כ איך היה..) כאן בדיוק נכנסת המחלקה ה"אובזרברית" שתפקידה לספר לכולם שB   עבר שינוי. ואובייקט A יהיה רשום אצל B  ויבקש ממנו, "B  יקירי, אנא עדכן אותי אם משתנה X...

Immutable Patternכל סטודנט שלומד על טיפוס מחרוזת בדוט נט יודע לדקלם "זה לא משתנה ערך אלא משתנה התייחסות שמתנהג כמו משתנה ערך" "It is not a value type just reference  type that acting like a value type" מה מיוחד בstring ממשתנים אחרים? אז בפשטות למחרוזת אין גודל ידוע מראש בשונה מטיפוסים אחרים (לא משנה מה ערכו של INT32, המקום בזיכרון יישאר זהה) מה שמשפיע על המקום שתופס המשתנה במרחב זיכרון הStack של התכנית, וזאת בעיה שהיתה לארכיטקטים של השפה. אבל מאחר  שstring שימושי אצלינו פעמים רבות כמו משתנה ערך, לדוגמא משמש מפתח בטבלת האש (Dictionary), ונרצה שיישאר קבוע ולא ישתנה לאחר שנוצר. לכן כשנגדיר משתנה מחרוזת הוא ייקבל מקום...

 Nullble Object Pattern מתכנתים בשפות מונחות עצמים מכירים היטב את הבעיה שלעיתים רפרנס לאובייקט הוא Null. לעיתים כי זאת הדרישה או המערכת שאתה אנו מתקשרים לעיתים מאתחול מאוחר של אובייקטים או מכל מיני סיבות לעיתים מכוונות וזה בסדר! אולם התבנית באה להתמודד אם מקרי הנפילה שבהם אנחנו נתפסים לא מוכנים כשעושים invoke על אובייקט. אחת השורות הכי נפוצות בקוד מודרני היא if Item != null  גם אם אין קשר כי כ"כ רגילים שהמערכת נופלת על Nulls אז למה לקחת סיכון ?? אבל nullble object זאת גם תבנית עיצוב עתיקה שבד"כ אנו נתקלים בצד המגעיל שלה שלה (להלן "אחת השורות הכי נפוצות..) אם כל האובייקטים היו עובדים על בסיס של null object לא היה סיכון של נפילה...

State Pattern VS. strategy Pattern  שני הפוסטים האחרונים שלי עסקו בשתי תבניות נפוצות ויעילות, הבעיה היא בהבנת ההבדל ביניהן ניתן לקרוא את הפוסטים המלאים כאן  state  startegy    ונסביר: הגדרתState  : אם הסטייט (מצב) של האובייקט השתנה בזמן ריצה נתנהג בהתאם. הגדרת Startegy: כמה צורת לטפל באירוע שנמשתמש ייבחר שמי להשתמש. אלו הם ההגדרות של התבניות. אולם נוצר בלבול ברגע שאני מסתכל בדוגמאות או בדיאגרמות הנפוצות להסביר את התבניות, בשתיהן אני משתמש בממשק חיצוני שכולל כמה מימושים, למקרים שונים ומפעיל את האובייקט שנראה לי נכון חותר למצב. ובכן התשובה היא שאכן State  כתבנית דומה מאוד ל Startegy אלא ההבדל הוא מי אחראי לפעול במקרים שנדרש טיפול שונה באירוע. בעוד שStsate מחזיקה מידע על מצב...

  תבנית בסיסית שאומרת דבר כזה "אם הסטייט (מצב) של האובייקט השתנה בזמן ריצה נתנהג בהתאם". בשביל הדוגמא נחשוב על מנגנון לניהול מיכל הדלק ברכב שלנו. נניח שלמיכל ישנם שלשה מצבים: ריק, מלא, ומצב ביניים. מאחר שמצב המיכל לא ידוע מראש ומשתנה "בזמן ריצה" נדרש מאתנו להגדיר אותו שיגיב בהתאם אכן, אם אנחנו יודעים מראש את כמות המצבים (כמו בדוגמא שלנו) הרי לא תהיה בעיה לטפל בהם. אבל אם נחשוב על אובייקט רחב, לדוגמא בזמן תכנון תשתית ונרצה לשמור על הרחבת היכולות שלו נבין טיפה יותר טוב את הרעיון. ונחזור לדוגמא: נרצה לקבל התנהגות שונה על כל מצב. לדוגמא , אם המיכל מלא לא יתאפשר תדלוק נוסף. אם הוא במצב ביניים...

Bridge הרעיון בתבנית Bridge הוא להפריד בין החוזה לבין המימוש כך שלא יהיו תלויים זה בזה. ז"א שאם יש לנו חוזה א' ומולו מימוש ב' אז ב' לא יכיר את א' אלא שחקן חדש שייקרא ג' יהווה את ערוץ הקשר ביניהם, וזאת בעצם התבנית. תבנית ה"גשר" פחות נפוצה אולי בשימוש בעיקר משום שיש לנו דרכים חדשות ליצור הפרדה וחוסר תלות בין הגדרת ממשק לבין המימוש שלו. בעיקר עקב השימוש הנפוץ בתבניות תכנוןכמו מודל שלש שכבות שיוצרים הפרדה וחוסר "תלות" בין חלקים שונים בתכנית שלנו.שימוש גיוני יכול להיות אם נצטרך להחליף מימוש של חוזה בזמן ריצה.בואו נבנה דוגמא בסיסית שלב אחרי שלב: 1.      נגדיר את החוזהpublic interface BridgePattern    {        void DoOperation();     ...

  תבנית המייצגת קונספט בסיסי שבו כמה מערכות מספקות לנו ממשק דומה אך עם מימושים פנימיים שונים, והמשתמש שיכול להיות אדם, או מכונה, ייבחר בזמן אמת באיזה "אלגוריתם" להשתמש:   דוגמא: חיישן "חכם" שמגן על גדר אלקטרונית. החיישן כולל כמה אופציות של טיפול ב"התרעות". אופציה לטיפול א': יצירת קשר עם המפקדה, סבירות האיום נמוכה. אופציה לטיפול ב': אזעקה , זוהה עצם חשוד עם סבירות איום גבוהה. אופציה לטיפול ג': רובה אוטומטי פותח באש לחיסול האיום. מה משותף לכל האופציות ?  ובכן אם נעטוף אותם בממשק זהה...

*הערה: הפוסט מיועד בעיקר למתכנתי WPF  עקב הדוגמא הנכללת בו. פיתוח בסביבת MVVM  כולל המון מעלות ויכולות, (נרחיב על תבניות כאלה בעתיד.) אבל גם חסרונות, את חלקם הייתי מגדיר כ"באגים" של השפה\Microsoft מאחר שעבודה עם Binding היא חלק מרכזי בWPF  היינו מצפים לקבל את היכולות הבסיסיות מוטמעות בפקדים השונים. מבחינת מפתחי UI החוסר לעיתים הוא קריטי. דוגמא טובה היא Multiple Selection ListBox . ונסביר, לפעמים נרצה לבחור מתוך אוסף איברים ברשימה יותר מאחד, זה תרחיש נפוץ ומקובל אולם ListBox  (ולא רק הוא) לא תומך  במצב של Binding לSelected Items אלא אך ורק לאייטם בודד. ולמה אני קורא לזה באג של השפה? כי יש ל"נאשם" שלנו (להלן ListBox) יש פרופרטי של selection...