[C++] משתנים ב public מול החזרה לפי רפרנס

[MasterDK]

היי, זה שאלה בעיקר של אין נכון/לא נכון או מקובל/לא מקובל לעשות.

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

//Point2DGetSet
class Point2D{
private:
 int x, y;

 public:
 int getX() const { return x; }
 int getY() const { return y; }
 void setX(int nx) { x = nx; }
 void setY(int ny) { y = ny; }
};
//Example
Point2D p;
p.setX(10);
p.setY(20);
DrawPoint(p.getX(), p.getY());



//Pint2DPublic
class Point2D{
public:
 int x, y;
};
//Example
Point2D p;
p.x = 10;
p.y = 20;
DrawPoint(p.x, p.y);


//Pint2DReference
class Point2D{
private:
 int x, y;

public:
 int& x() { return x; }
 int& y() { return y; }
};
//Example
Point2D p;
p.x() = 10;
p.y() = 20;
DrawPoint(p.x(), p.y());

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

אם לקיחת כל הבדרים הללו בחשבון מה נחשבת השיטה הכי עדיפה? מה השיטה הכי עדיפה עאםם לא אכפת לי בדיקת ערכים (כמו נקודה במרחב, היא יכולה להימצא בכל קוורדינטה, לעומת לדוגמא מחלקה של צבע שמוגבלת לערכים של 0 עד 255 עבור כל קופמוננט)?

[Zelig]

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

השאלה העיקרית אולי שצריך לשאול: האם יש ערך מוסף לעבודה הזו? האם זה יתרום משהו?

מייד אחרי השאלה הבאה היא: האם אני חושב שסביר שיהיה צורך בכך בעתיד? האם המאמץ עכשיו שווה את התועלת העתידית?

באופן ספציפי, לגבי נקודה דו מימדית, רוב המקרים שראיתי (חלק באים מהעולם של מידול גיאומטרי או אפקטים דו מימדיים) ה-data members הם פומביים ופשוטים, מכל מני סיבות:

* המערכת מתוכננת ממילא שיהיה רק X ו-Y על מנת לחסוך ביצועים וזכרון. אין טעם ב-data נוסף שהוא private.

* לפעמים דווקא מדובר בקונספט פשוט מדי ולא מרכזי, וחבל לבזבז עליו זמן תכנון פיתוח ודיבוג API. עושים struct עם X ו-Y ויאללה זהו.

* רוצים שיהיה Plain Old Data על מנת לאפשר פעולות פשוטות ללא סיבוכים.

* תאימות עם C.

* השימוש כ"כ נפוץ ורוצים שהקוד יהיה קצר וקריא.

* אין ערך מוסף בשימוש ב-accessors.

* עצלנות.

---

עריכה:

כמובן שיש גם סיבות מצויינות כן להשתמש ב-accessors.

באותו נושא: http://www.kirit.com/C%2B%2B%20killed%20the%20get%20%26%20set%20accessors

מציע שיטה לכתיבת accessors. אני באופן אישי לא מת על חלק מהרעיונות שם, כי הם מוסיפים syntactic sugar שנראה לי מסוכן קצת.

http://stackoverflow.com/questions/372700/get-set-in-the-c-world-faux-pas

[MasterDK]

תודה רבה על התגובה!

הרעיון של נוקדה בדו מימד היה לצורך המחשה.

אני עובד על מנוע משחק בין היתר אני נתקל במחלקון כגון ווקטור, מימדים (גודל של משהוא), צבע. כשאין לי צורך בפעולות מורכבות כגון חיבור/חיסור או משהוא אחר (לדוגמא ניקח את מחלקה Dimensions2 שהיא אמורה סך הכל להחזיק גודל של משהוא דו מימדי [במקרה שלי משתמשת עבור גדול של חלון] אין לי צורך לחבר מימדים, לחלק מימדים או לבצע פעולות עליהן) אז אני משתמש ב struct פשוט, ושוב בגלל שאין הגבלה לוגית על גודל של משהוא (בין אם זה חלון שגודלו מוגדר על ידי Dimensions2 ובין אם זה טקסטורה שגודלה מוגדר על ידי Dimensions3 [כי היא יכולה להיות תלת-מימדית]) אז הכל public עם שתי constructors אחד ריק והשני לא.

אבל ווקטור לדוגמא זה מחלקה מורכבת שניתן לבצע עליה פעולות מטמטיות וכו', אבל גם פה אין הגבלה על גודל של הרכיבים של הווקטור ולכן גם פה המשתנים x y z הם public, לעומת צבע שאותו אני רוצה להגביל לטווח ערכים של 0 עד 1.0 ולכן בתוך ה setter אני צריך לבצע פעולה נוספת שמטרה לבדוק שערך לא יצא מחוץ לגובולת ולעדכן אותו במקרה הוא יצא בגלל זה אני לא יכול לפתוח גישה ציבורית לרכיבים red green blue alpha.

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

[Zelig]

אלה החיים, אחידות היא חשובה אבל לא זה לא הכל.

A foolish consistency is the hobgoblin of little minds.

[MasterDK]

חחח יש בזה משהוא

תודה רבה על העזרה!