ארכיון

ארכיון לקטגוריה ‘תכנות’

התארחתי בפודקאסט Out of Memory

OutOfMemory

מעניין שהאותיות O ו M בצבע אחר 🙂

אני מכיר את עופר (לינקדאין, בלוג) ואת מיכה כבר הרבה שנים.

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

מאז חלפו הרבה סיביות במרשתת. כל אחד מאיתנו התפתח מקצועית. עופר ומיכה מגישים ביחד פודקאסט מעולה בשם Out of Memory, שם הם מדברים על תוכנה, טכנולוגיה ועוד דברים שבסביבה, כמו למשל חידות המוסד.

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

די התרגשתי להתארח שם, וכנראה בגלל זה דיברתי עוד יותר לאט מהרגיל שלי.. אז המלצה למי שמאזין – אל תשכחו שאפשר להריץ במהירות של 1.25 ואל תתיאשו! 😀

וכמובן, תודה לעופר ולמיכה!

קישור ישיר לפרק.

[זה פוסט מהסוג של ״זה קרה אבל קצת מזמן״]

קטגוריות:טכנולוגיה, תכנות תגיות:

שוב על enum

2 ספטמבר, 2016 5 תגובות

כבר יצא לי לכתוב בעבר על שימוש לא נכון ב enum.

ויצא לי להתייחס לנקודה הזו בעבודה עם קולגות, די הרבה פעמים.

מצד אחד, מאוד נוח (ומפתה) דווקא כן לעטוף ערימה של קבועים ב enum, כי זה מעלה את הפרודוקטיביות כאשר משתמשים ב IDE כמו Visual Studio או IntelliJ Idea. שם כל מנגנוני ההשלמה האוטומטית פועלים יפה.

מצד שני, וזה שיקול הנדסי של נכונות הקוד, אם הקבועים האלה ניתנים לשינוי, וביום בהיר אחד אנחנו אכן מוסיפים ערך או גורעים ערך…
אז בכל מקום בקוד שבו משתמשים ב enum ששינינו, אנחנו צריכים לוודא שהכל תקין וששום דבר לא נשבר.

הבעיה

במקום לנפנף בידיים, אני אסביר ע"י קוד (ב Java, שבה אני מתכנת כיום).

נניח שיש לנו את ה enum הבא:

ויש לנו בקוד תנאי כזה:

עכשיו, בגלל שזה enum, אז נכון לזמן כתיבת הקוד, אם התנאי מתקיים, כלומר x הוא אכן Green, אז הבלוק של ה else לא יתבצע. כלומר, וזה ניואנס קריטי: הקוד של ה else יתבצע רק אם x הוא White או אם x הוא Blue.

ובכן, אם נוסיף עכשיו ערך חדש ל enum שלנו, נניח Brown:

התוכנית שלנו רצה, ועכשיו ערכו של x הוא Brown.

האם הקוד של ה else יתבצע?

ברור שיתבצע, הרי x איננו Green.

אבל ראינו קודם, לפני השינוי של ה enum, שהקוד של ה else אמור להתבצע רק במקרה ש x הוא White או Blue.

בקיצור, הוספת ערך ל enum שלנו שברה את הלוגיקה של הקוד.

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

זה כל הסיפור.

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

שינוי של enum עלול לשבור נכונות של קוד.

פשרות

החיים מלאי פשרות. וזה נכון גם בהנדסת תוכנה.

יכול לבוא מישהו ולומר: אוקיי, ברור לי מהו הסיכון. ולמרות זאת, הפרודוקטיביות חשובה לי. מה עושים?

פשרה ראשונה – ליצור קבועים שלא דרך enum

ב Java זה די פשוט: יוצרים public static final ובזה תמה יצירת קבוע סטטי.

מה הרווחנו:

  • קוד נכון יותר, שפתוח לשינויים
  • השלמה אוטומטית

מה איבדנו:

  • את היכולת לעבור על כל הקבועים האלה (אם ממש רוצים – פתיר ע"י מעטפת ב class יחיד ומעבר ע"י reflection).

פשרה שניה – ליצור enum עם חשיפה מינימלית

אפשר ליצור enum שיהיה private ברמת ה class (או ה package), ואז הסיכון של שבירת הקוד מצטמצם לטווח ההכרה של ה enum שיצרנו.

מה הרווחנו:

  • את כל היתרונות של enum: השלמה אוטומטית, מעבר על הערכים

מה הפסדנו:

  • פוטנציאל לשבירת קוד, אבל בסיכון מצומצם

סיכום

עבודה נכונה עם enum – מתחילה עם הבנה טובה ויסודית של הקונספט עצמו.

במיוחד ב Java, מפתה לעבוד עם enum כמעטפת של נתונים (שיכולים להשתנות עם הזמן), משיקולים של פרודוקטיביות.

כאשר עובדים עם enum שעוטף נתונים, מסתכנים בשבירת לוגיקה של קוד.

אפשר להתפשר ובכל זאת לעבוד עם enum תוך צמצום הסיכון של שבירת לוגיקת קוד, או לוותר על ה enum וליצור סביב הנתונים מעטפת סמנטית של קבועים.

קידוד נעים!

קטגוריות:תכנות תגיות:
Quantcast