Getters setters עכשיו כבר התבלבלתי

המחברת של השבוע עוררה בי שוב את ההתלבטות לגבי פעולות גישה ושינוי :upside_down_face:
מקווה שאסביר את עצמי כמו שצריך…

שבוע שעבר כשדיברנו על תכונות/פעולות פרטיות ומוגנות, צוין שבאופן כללי פייתון היא שפה למבוגרים אחראיים (“כולנו מבוגרים בעלי שיקול דעת”). למדנו גם שפייתון מאפשרת בכל מיני דרכים פתלתלות לעקוף את המוסכמות בעניין גישה לתכונות ופעולות כאלו.
בנוסף למדנו שמתכנתים שמגיעים משפות אחרות התרגלו לתת גישה עקיפה דרך גטרס וסטרס.
הסקתי מהנ"ל שאין סיבה שאשתמש בגטרס וסטרס בפייתון. הרי אם המוסכמה היא שכשהגדרתי שלא נוגעים - לא נוגעים אז אין סיבה וממילא מי שירצה בכך - לא יצטרך את גטרס וסטרס בשביל זה.

השבוע במחברת יש דוגמה (נגדית) שמשתמשת בגטרס וסטרס.
אז שתי שאלות:

  1. אם הדוגמה מופיעה, כן מקובל להשתמש בגטרס וסטרס גם בפייתון?
  2. בהנחה שהתשובה ל-1 היא כן: למה לא מספיק להסתמך על המוסכמה? קראתי פוסטים בפורום ונאמר שכדאי להקשות על הגישה למרות שהגדרנו כפרטיות/מוגנות. החשיבה שלי היא שאם יש מוסכמה אחת, למה צריך להעמיס עליה עוד גדר? הרי אולי גם הגדר הזו לא תספיק?

על שאלה 2 ענו באותה מחברת כך’:כשכותבים
קו תחתון אחד ואז משנים אותו באופן פרטי אז זה נחשב כחצוף ולא מנומס .
אם יש 2 קווים תחתונים יש להמנע ככל שניתן מלשנות שם משהו באופן עצמאי ולא להשתמש במשתנה / פעולה באופן עצמאי…פשוט לא עושים את זה

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

מצטער…רגע…
אז תזכירי לי מה גטרס וסטרס? כי חשבתי שאלו הקווים התחתונים…

יש פה קפיצה לוגית קצת גדולה מדי ונראה לי שכאן הפער :slight_smile:

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

  1. התכונה היא פרט מימוש פנימי של המחלקה ועדיף לא לשנות אותה כי אין לה נגיעה ישירה עם המשתמש.
  2. התכונה כן נוגעת למשתמש (לדוגמה: רשימת אומנים), אבל יש דברים נוספים שאנחנו רוצים שיקרו כשקוראים/כותבים לתכונה הזו, או שאנחנו חושבים שיהיה יותר נוח למשתמש אם ננגיש לו ממשק נעים (add_artist, remove_artist) שיטפל עבורו בכל מקרי הקצה.

במקרה השני לפעמים כותבים פעולות ש"יעטפו" את התכונה המוגנת (לפעמים רק setters, לפעמים רק getters ולפעמים שניהם), כדי לספק למשתמש ממשק נוח לעבוד עם המחלקה.
זה לא שאנחנו לא סומכים על המשתמש במחלקה שלנו, ואם נדבר פילוסופית, המטרה היא פחות החבאה ויותר לתת למשתמש במחלקה ממשק שנעים לו לעבוד איתו. ככה הוא לא יצטרך לחשוב על איך artists בנויה או איך מספקים אותה. אנחנו מספקים לו אבסטרקציה כדי להוריד את הסיבוך שיכול לעלות בשימוש בקוד שלנו.

3 לייקים

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

2 לייקים