משנים מפתחות, מאבדים ערכים

TL;DR: כאשר אתה משתמש באובייקטים הניתנים לשינוי כמפתחות באוספים גיבובים, שינוים שובר חוזים.

בעיות 😔

• ערכים אבודים
• איתור באגים קשה
• הפרת עקרון ההפתעה הפחותה
• התנהגות בלתי צפויה

פתרונות 😃

1. השתמש באובייקטים בלתי ניתנים לשינוי כמפתחות.
2. עוקף שווה/hashCode היטב.
3. השתמש בשדות אחרונים (אם השפה שלך מאפשרת זאת)
4. Rehash לאחר מוטציה (זהו פתרון הנדסת יתר)

הקשר 💬

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

זה קורה בגלל שקוד ה-hash משתנה והאוסף לא יכול למצוא את האובייקט בדלי הנכון.

קוד לדוגמה 📖

לא נכון ❌

 class MutableKey { int id; MutableKey(int newId) { this.id = newId; } @Override public int hashCode() { return this.id; } @Override public boolean equals(Object objectToCompare) { if (this == objectToCompare) return true; MutableKey that = (MutableKey) objectToCompare; return id == that.id; } } MutableKey key = new MutableKey(42); Map<MutableKey, String> map = new HashMap<>(); map.put(key, "Yes Album"); // The key mutates key.id = 90125; // Now you cannont retrieve the album System.out.println(map.get(key)); // Output: null

נכון 👉

 class ImmutableKey { private final int id; ImmutableKey(int newId) { this.id = newId; } @Override public int hashCode() { return this.id; } @Override public boolean equals(Object objectToCompare) { if (this == objectToCompare) return true; ImmutableKey that = (ImmutableKey) objectToCompare; return id == that.id; } } ImmutableKey key = new ImmutableKey(42); Map<ImmutableKey, String> map = new HashMap<>(); map.put(key, "Yes Album"); System.out.println(map.get(key)); // Output: Yes Album

זיהוי IP

• חצי אוטומטי

אתה יכול לזהות את הריח הזה על ידי בדיקה אם אתה משתמש באובייקטים הניתנים לשינוי כמפתחות באוספים מבוססי hash.

כלים אוטומטיים כמו linters או בדיקות IDE יכולים גם לסמן מפתחות הניתנים לשינוי.

תגיות 🏷️

• השתנות

רמה 🔋

• ביניים

למה הבייג'יון חשוב 🗺️

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

בעולם האמיתי, מפתחות הם לרוב בלתי ניתנים לשינוי (למשל, מזהים, שמות).

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

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

דור AI 🤖

מחוללי AI עשויים ליצור את הריח הזה אם הם יוצרים אובייקטים הניתנים לשינוי כמפתחות מבלי להתחשב בהשלכות.

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

זיהוי בינה מלאכותית 🥃

מחוללי AI יכולים לזהות את הריח הזה עם הוראות לנתח את השימוש באובייקטים הניתנים לשינוי באוספים מבוססי hash ולסמן בעיות פוטנציאליות.

אתה יכול להורות ל-AI לחפש מחלקות ללא שדות סופיים או שיטות שמשנות את מצב האובייקט לאחר היצירה.

נסה אותם! 🛠

זכור: עוזרי AI עושים הרבה טעויות

מסקנה 🏁

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

השתמש באובייקטים בלתי ניתנים לשינוי כדי למנוע בעיה זו.

יחסים 👩‍❤️‍💋‍👨

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxiv

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxv

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxiv

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxvi

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xviii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxvi

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xlii

מידע נוסף 📕

כתב ויתור 📘

ריחות קוד הם דעתי .

קרדיטים 🙏

תמונה מאת Kathyryn Tripp ב- Unsplash

התכונה החשובה ביותר של תוכנית היא האם היא משיגה את כוונת המשתמש שלה.

CAR Hoare

מאמר זה הוא חלק מסדרת CodeSmell.