none
Property, למה להשתמש בו כשהset & get, לא עושים שום דבר מיוחד?

    שאלה

  • התעוררתי לשאלה כשקראתי על אחד מחידושי הVB 2010: בנייה אוטומטית של מאפיינים, כלומר, די להצהיר כך:

     

    Property VariableName As Integer
    

     

    שזה שקול ל:

     

    Private pVariableName As Integer
    
    Property VariableName As Integer
     Get
     Return pVariableName 
     End Get
     Set(ByVal value As Integer)
     pVariableName = value
     End Set
    End Property
    

     

    וכך היה כבר בC# מגירסה 3.0

     

     public int VariableName{ get; set; }
    

    כעת השאלה שלי היא: אם אין מתודה מסויימת לאימות או עיצוב של הנתונים, למה לא להכריז סתם על משתנה public ככה?

    האם יש חיסרון 

     public int VariableName; 
    

     

    או בVB:

     

     public VariableName As Integer
    

     

     

     מה התועלת של property על משתמה public בכזה מקרה?

     


    יום ראשון 08 מאי 2011 08:02

תשובות

  • אין הרבה הבדל בין public field ל property כל עוד ה property לא מכיל פונקציונליות על ה get ו/או ה set שלו (למשל, וידוא קלט, או lazy loading).

    עד שמגיעים ל reflection.

    כשמבצעים reflection מגלים התנהגות שונה בין השניים. ברפלקשן, property הופך להיות מתודה, או שתי מתודות (אפשר לבדוק עם ILSpy, התחליף שלי לרפלקטור).

    זאת ועוד, סריאליזציה אוטומטית, כמו זו שמתקבלת ע"י האטריביוט [Serializable], מתבצעת על פרופרטיז, ולא על fields.

    עניין נוסף: interfaces.

    כשכותבים interface, אפשר רק להצהיר על properties, ולא על fields.

     

    לסיכום: בשימוש הכי פשוט של השמה וקריאה של ערכים ל members של class, אין הרבה הבדל, ואני ממליץ לעבוד עם fields במקרים שכאלה.

    אם צריך פונקציונליות מעט שונה, כמו סיריאליזציה נוחה ל XML (וממנו) או להוציא interface מתוך class נתון, יש להשתמש ב properties.

    HTH :-)

    • סומן כתשובה על-ידי לומדים יום ראשון 08 מאי 2011 09:51
    יום ראשון 08 מאי 2011 08:33
  • אם השדה הוא public עדיף תמיד לעבוד עם property.

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

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

     


    Arik Poznanski
    blogs.microsoft.co.il/blogs/arik

    • סומן כתשובה על-ידי Arik Poznanski יום שני 09 מאי 2011 13:18
    יום ראשון 08 מאי 2011 12:49

כל התגובות

  • אין הרבה הבדל בין public field ל property כל עוד ה property לא מכיל פונקציונליות על ה get ו/או ה set שלו (למשל, וידוא קלט, או lazy loading).

    עד שמגיעים ל reflection.

    כשמבצעים reflection מגלים התנהגות שונה בין השניים. ברפלקשן, property הופך להיות מתודה, או שתי מתודות (אפשר לבדוק עם ILSpy, התחליף שלי לרפלקטור).

    זאת ועוד, סריאליזציה אוטומטית, כמו זו שמתקבלת ע"י האטריביוט [Serializable], מתבצעת על פרופרטיז, ולא על fields.

    עניין נוסף: interfaces.

    כשכותבים interface, אפשר רק להצהיר על properties, ולא על fields.

     

    לסיכום: בשימוש הכי פשוט של השמה וקריאה של ערכים ל members של class, אין הרבה הבדל, ואני ממליץ לעבוד עם fields במקרים שכאלה.

    אם צריך פונקציונליות מעט שונה, כמו סיריאליזציה נוחה ל XML (וממנו) או להוציא interface מתוך class נתון, יש להשתמש ב properties.

    HTH :-)

    • סומן כתשובה על-ידי לומדים יום ראשון 08 מאי 2011 09:51
    יום ראשון 08 מאי 2011 08:33
  • אם השדה הוא public עדיף תמיד לעבוד עם property.

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

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

     


    Arik Poznanski
    blogs.microsoft.co.il/blogs/arik

    • סומן כתשובה על-ידי Arik Poznanski יום שני 09 מאי 2011 13:18
    יום ראשון 08 מאי 2011 12:49