29 בNovember 2012
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...
22 בNovember 2012
Immutable Patternכל סטודנט שלומד על טיפוס מחרוזת בדוט נט יודע לדקלם
"זה לא משתנה ערך אלא משתנה התייחסות שמתנהג כמו משתנה ערך"
"It is not a value type
just reference type that acting like a
value type"
מה מיוחד בstring ממשתנים אחרים? אז בפשטות
למחרוזת אין גודל ידוע מראש בשונה מטיפוסים
אחרים (לא משנה מה ערכו של INT32, המקום בזיכרון יישאר זהה)
מה שמשפיע על המקום שתופס המשתנה במרחב זיכרון הStack של התכנית,
וזאת בעיה שהיתה לארכיטקטים של השפה.
אבל מאחר שstring שימושי אצלינו פעמים רבות כמו משתנה ערך,
לדוגמא משמש מפתח בטבלת האש (Dictionary), ונרצה שיישאר קבוע ולא
ישתנה לאחר שנוצר.
לכן כשנגדיר משתנה מחרוזת הוא ייקבל מקום...
16 בNovember 2012
Nullble
Object Pattern
מתכנתים בשפות מונחות עצמים מכירים היטב את הבעיה שלעיתים רפרנס לאובייקט הוא Null.
לעיתים כי זאת הדרישה או המערכת שאתה אנו מתקשרים לעיתים מאתחול מאוחר של אובייקטים
או מכל מיני סיבות לעיתים מכוונות וזה בסדר! אולם התבנית באה להתמודד אם מקרי הנפילה שבהם
אנחנו נתפסים לא מוכנים כשעושים
invoke על אובייקט.
אחת השורות הכי נפוצות בקוד מודרני היא if Item
!= null גם אם
אין קשר כי
כ"כ רגילים שהמערכת נופלת על
Nulls אז למה לקחת
סיכון ??
אבל nullble object זאת גם
תבנית עיצוב עתיקה שבד"כ אנו
נתקלים בצד המגעיל שלה שלה (להלן
"אחת השורות הכי
נפוצות..)
אם כל האובייקטים היו עובדים על
בסיס של null object לא היה
סיכון של נפילה...
12 בNovember 2012
State Pattern VS. strategy Pattern
שני
הפוסטים האחרונים שלי עסקו בשתי תבניות נפוצות ויעילות, הבעיה היא בהבנת ההבדל
ביניהן
ניתן לקרוא את הפוסטים המלאים כאן state startegy
ונסביר:
הגדרתState : אם הסטייט (מצב) של האובייקט השתנה בזמן ריצה
נתנהג בהתאם.
הגדרת Startegy: כמה צורת לטפל באירוע
שנמשתמש ייבחר שמי להשתמש.
אלו הם ההגדרות של התבניות. אולם נוצר בלבול ברגע שאני מסתכל בדוגמאות
או בדיאגרמות
הנפוצות להסביר את התבניות, בשתיהן אני משתמש בממשק חיצוני שכולל כמה
מימושים,
למקרים שונים ומפעיל את האובייקט שנראה לי נכון חותר למצב.
ובכן התשובה היא שאכן State כתבנית דומה מאוד ל Startegy אלא ההבדל הוא מי אחראי
לפעול במקרים שנדרש טיפול שונה באירוע.
בעוד שStsate מחזיקה מידע על מצב...
תבנית בסיסית שאומרת דבר כזה "אם הסטייט (מצב) של האובייקט
השתנה בזמן ריצה נתנהג בהתאם".
בשביל הדוגמא נחשוב על מנגנון לניהול מיכל הדלק ברכב שלנו.
נניח שלמיכל ישנם שלשה מצבים: ריק, מלא, ומצב ביניים.
מאחר שמצב המיכל לא ידוע מראש ומשתנה "בזמן ריצה" נדרש
מאתנו להגדיר אותו שיגיב בהתאם
אכן, אם אנחנו יודעים מראש את כמות המצבים (כמו בדוגמא שלנו) הרי לא
תהיה בעיה לטפל בהם.
אבל אם נחשוב על אובייקט רחב, לדוגמא בזמן תכנון תשתית ונרצה לשמור על
הרחבת היכולות שלו נבין
טיפה יותר טוב את הרעיון.
ונחזור לדוגמא: נרצה לקבל התנהגות שונה על כל מצב.
לדוגמא , אם המיכל מלא לא יתאפשר תדלוק נוסף. אם הוא במצב ביניים...
7 בNovember 2012
Bridge
הרעיון בתבנית Bridge הוא להפריד בין החוזה
לבין המימוש כך שלא יהיו תלויים זה בזה.
ז"א שאם יש לנו חוזה א' ומולו מימוש ב' אז ב' לא יכיר את א' אלא
שחקן חדש שייקרא ג'
יהווה את ערוץ הקשר ביניהם, וזאת בעצם התבנית.
תבנית ה"גשר" פחות נפוצה אולי בשימוש בעיקר משום שיש לנו
דרכים חדשות ליצור הפרדה וחוסר תלות בין הגדרת ממשק לבין המימוש שלו. בעיקר עקב השימוש הנפוץ
בתבניות תכנוןכמו מודל שלש שכבות שיוצרים הפרדה וחוסר "תלות" בין חלקים
שונים בתכנית שלנו.שימוש גיוני יכול להיות אם נצטרך להחליף מימוש של חוזה בזמן ריצה.בואו נבנה דוגמא בסיסית שלב אחרי שלב:
1.
נגדיר את
החוזהpublic interface BridgePattern { void DoOperation();
...
4 בNovember 2012
תבנית המייצגת קונספט בסיסי שבו כמה מערכות מספקות לנו ממשק דומה
אך עם מימושים פנימיים שונים, והמשתמש שיכול להיות אדם, או מכונה,
ייבחר
בזמן אמת באיזה "אלגוריתם" להשתמש:
דוגמא:
חיישן "חכם" שמגן על גדר אלקטרונית. החיישן כולל כמה
אופציות של טיפול ב"התרעות".
אופציה לטיפול א': יצירת קשר עם המפקדה, סבירות האיום נמוכה.
אופציה לטיפול ב': אזעקה , זוהה עצם חשוד עם סבירות איום גבוהה.
אופציה לטיפול ג': רובה אוטומטי פותח באש לחיסול האיום.
מה משותף לכל האופציות ? ובכן
אם נעטוף אותם בממשק זהה...
1 בNovember 2012
*הערה: הפוסט מיועד בעיקר למתכנתי WPF עקב
הדוגמא הנכללת בו.
פיתוח בסביבת MVVM כולל המון מעלות ויכולות, (נרחיב על תבניות כאלה
בעתיד.)
אבל גם חסרונות, את חלקם הייתי מגדיר כ"באגים" של השפה\Microsoft
מאחר שעבודה עם Binding היא חלק מרכזי בWPF היינו מצפים לקבל את היכולות הבסיסיות
מוטמעות בפקדים השונים. מבחינת מפתחי UI החוסר לעיתים הוא קריטי.
דוגמא טובה היא Multiple Selection ListBox .
ונסביר, לפעמים נרצה לבחור מתוך אוסף איברים ברשימה יותר מאחד, זה
תרחיש נפוץ ומקובל
אולם ListBox (ולא רק הוא) לא תומך במצב של Binding לSelected
Items אלא אך ורק לאייטם בודד.
ולמה אני קורא לזה באג של השפה? כי יש ל"נאשם" שלנו (להלן ListBox)
יש פרופרטי של selection...