Yatta! – I did it

הבלוג הזה היה פחות פעיל בשנים האחרונות, כי סיבות.

אבל כן קרו לי דברים מעניינים פה ושם. אז בקרוב אני אפרסם כאן פוסטים על בסגנון ״ככה היה וזה מה שקרה״.

בקיצור, לשחזר את ההיסטוריה, אבל בקטע טוב. stay tuned.

כבר יצא לי לכתוב בעבר על שימוש לא נכון ב 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 וליצור סביב הנתונים מעטפת סמנטית של קבועים.

קידוד נעים!