C# : Property vs. field


Recently there was an email-thread in the internal C# group on the usage of property vs. field.


 


The question raised was in case a class implements properties, is it still ok to go ahead and access the field directly from other methods of the same class. The thread also covered when it is ok to add properties.


 


This is a decision we take everyday when writing code. Some great people pitched in to give there opinion.  The outcome is something like this


 



  1. In case you are designing a class library and the consumer is not under your control then add properties for all public fields to prepare for future needs to add checks to field access

  2. In case you can version (change) the client code as well, do not add properties just because its good, or because you think you might need functionality of checks, lazy loading in the future. In case you do not need these features right-away allow clients to directly use fields. With the new refactoring features of VS2005 changing all references to the field to properties is a non-issue.

  3. With the above two filtering you are sure that once you have a property its definitely going to do some additional work and so only use the property from everywhere (including methods from same class).

 

Comments (11)

  1. Edward Smit says:

    May I propose an aditional step?

    2a. In case there might be a scenario where V1.x DataBinding to your class makes sense, add properties as V1.x DataBinding does not work with fields on Custom Objects, only with properties (don’t know yet how this is in V2)

    And what was the outcome on the question raised? Is it still ok to go ahead and access the field directly from other methods of the same class?

  2. See the third point. Eliminate properties based on 1 and 2. In case there is a property use it from the ALL other methods

  3. Edward Smit says:

    Ehm, right. Don’t know how I missed that one. Must have been to pre-occupied with my 2a step 🙂

  4. Sean Chase says:

    Good lord, this is amazing. Is there a reason the new xsd.exe utility uses properties now instead of methods? Any issues with databinding at all? Versioning? Please excuse the hell out of me while I just go right ahead and default to using properties for everything public and protected. I feel icky if I use fields that are not private to the class. Call me OC I guess. BTW – thank the makers for the new "prop" expansion in VS2005. Which is easier, using the new prop expansion or refactoring all of your fields later? ‘Nuff said. 🙂

  5. Sean Chase says:

    Good lord, this is amazing. Is there a reason the new xsd.exe utility uses properties now instead of methods? Any issues with databinding at all? Versioning? Please excuse the hell out of me while I just go right ahead and default to using properties for everything public and protected. I feel icky if I use fields that are not private to the class. Call me OC I guess. BTW – thank the makers for the new "prop" expansion in VS2005. Which is easier, using the new prop expansion or refactoring all of your fields later? ‘Nuff said. 🙂

  6. lummie says:

    What about performance considerations? Are there any ? Is there significant performance benefits in using fields directly rather than calling the get / set functions ?

  7. Since get.set functions will be inlined, I don’t think there’d be any perf hit in using them. However, I didn’t profile to see the diff

  8. Your second bullet point is not correct. When you change a public field to a property, you may find that some code was using the public field as an out- or ref-parameter. In that case the refactoring will not be straightforward.

    I’ve written more about this here: http://kristofverbiest.blogspot.com/2007/02/public-fields-and-properties-are-not.html

  9. George says:

    Yeah. The insistance on properties everywhere was nonsense. Properties are intended to agument fields by allowing side-effects. Consequently, they  are suppose to be interchangable. In fact, the distinction between fields and functions is also nonsense. Anyways, the limitation that properties have of not allowing direct a reference/pointer to it is an oversight that should have been corrected by now (delegates!); perhaps in C# v3.6.

  10. Mario says:

    Properties are not always inlined. The first time the property is invoked is like any other method and much more slower than fields. All the performances test using loops of several million of iterations that you can see all over Internet do not take in consideration that fact. On the other hand with properties you can not do this:

    Funtion(ref C.Property);

    or

    C.Property.x = value;

    Properties are usefull in some ways, but I am with George, the insistend¡ce to be used everywhere is nonsense.

Skip to main content