שאלת מבחן בתכנות מונחה עצמים - אוניברסיטת בר-אילן 2019 - הסתרת מידע

במסגרת עבודתו בחברת תוכנה גדולה, ליאופולד כתב היררכיית מחלקות והגדיר במחלקת הבסיס שדה בנראות `protected`. לאחר שסיים, התברר לו שהנחיות כתיבת הקוד של החברה אוסרות במפורש על שדות בנראות זו. מה מבין הבאים הוא הפתרון הטוב ביותר לבעיה של ליאופולד, לפי עקרונות התכנות שלמדנו? 1. ליאופולד יכתוב את כל הקוד מחדש לפי הנחיות החברה. 2. ליאופולד ישנה את הנראות של השדה ל-`private`, וימחק את כל הקוד שמשתמש בו מחוץ למחלקה. 3. ליאופולד ישנה את הנראות של השדה ל-`private`, וכדי למנוע שגיאות קומפילציה יעתיק את הגדרת השדה לכל מחלקה יורשת שהשתמשה בו קודם לכן. 4. ליאופולד ישנה את הנראות של השדה ל-`private`, יוסיף עבורו `getter` ו-`setter` בנראות `protected` או `public` לפי הצורך וישנה את הקוד להשתמש בהם.

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

פתרון: הפתרון הנכון והטוב ביותר הוא **אפשרות 4**. על פי עיקרון **הסתרת המידע** (Encapsulation), אחד מעקרונות היסוד של תכנות מונחה עצמים, יש להגביל את הגישה הישירה למצב הפנימי (השדות) של אובייקט. שדה `protected` מפר במידה מסוימת את העיקרון הזה, מכיוון שהוא מאפשר למחלקות יורשות גישה ישירה ובלתי מבוקרת לשדה, מה שיוצר תלות חזקה (coupling) בין מחלקת הבסיס למחלקות היורשות. שינוי במימוש של מחלקת הבסיס עלול לשבור את המחלקות היורשות. הפתרון הנכון הוא להפוך את השדה ל-`private`, ובכך להבטיח שהוא נגיש רק מתוך המחלקה עצמה. כדי לאפשר למחלקות היורשות (ולקוד חיצוני, במידת הצורך) לגשת לערך או לשנות אותו בצורה מבוקרת, מוסיפים מתודות גישה (accessor/getter) ומתודות עדכון (mutator/setter). * **Getter**: מתודה (למשל `getX()`) שמחזירה את ערך השדה. * **Setter**: מתודה (למשל `setX(value)`) שמאפשרת לקבוע ערך חדש לשדה. מתודה זו יכולה להכיל לוגיקה נוספת, כגון בדיקות תקינות (ולידציה) על הערך החדש, כדי להבטיח את שלמות המצב של האובייקט. הנראות של ה-getter וה-setter (במקרה זה, `protected` או `public`) תקבע מי יכול להשתמש בהן. פתרון זה משמר את הפונקציונליות הנדרשת תוך שמירה על עקרונות תכנות נכונים, גמישות ותחזוקתיות של הקוד. **ניתוח שאר האפשרויות:** 1. **כתיבת כל הקוד מחדש:** פתרון דרסטי, לא יעיל ובזבזני. עקרונות תכנות טובים נועדו למנוע מצבים כאלה. 2. **שינוי ל-private ומחיקת הקוד המשתמש:** פתרון זה שובר את הפונקציונליות של המחלקות היורשות שהסתמכו על השדה. 3. **שינוי ל-private והעתקת השדה:** פתרון זה הוא אנטי-תבנית (anti-pattern) מובהק. הוא יוצר שכפול קוד, פוגע בעקרון "אל תחזור על עצמך" (DRY), ומקשה מאוד על תחזוקת הקוד בעתיד (כל שינוי יצטרך להתבצע בכל המחלקות המעתיקות).