Welcome to MSDN Blogs Sign in | Join | Help

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).

 

Published Thursday, September 22, 2005 2:06 PM by abhinaba
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: C# : Property vs. field

Thursday, September 22, 2005 5:24 AM by Edward Smit
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?

# re: C# : Property vs. field

Thursday, September 22, 2005 7:35 AM by abhinaba
See the third point. Eliminate properties based on 1 and 2. In case there is a property use it from the ALL other methods

# re: C# : Property vs. field

Thursday, September 22, 2005 10:35 AM by Edward Smit
Ehm, right. Don't know how I missed that one. Must have been to pre-occupied with my 2a step :-)

# re: C# : Property vs. field

Thursday, September 22, 2005 12:35 PM by Sean Chase
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. :-)

# re: C# : Property vs. field

Thursday, September 22, 2005 12:37 PM by Sean Chase
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. :-)

# re: C# : Property vs. field

Tuesday, October 04, 2005 11:32 AM by ericgu
Here's my blog post about this issue:

http://blogs.msdn.com/ericgu/archive/2005/09/19/471327.aspx

# re: C# : Property vs. field

Wednesday, November 23, 2005 10:38 AM by lummie
What about performance considerations? Are there any ? Is there significant performance benefits in using fields directly rather than calling the get / set functions ?

# re: C# : Property vs. field

Thursday, November 24, 2005 2:03 AM by abhinaba
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

# re: C# : Property vs. field

Tuesday, February 13, 2007 9:15 AM by Kristof Verbiest

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

# re: C# : Property vs. field

Tuesday, December 04, 2007 8:14 PM by George

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.

# re: C# : Property vs. field

Monday, March 16, 2009 8:15 PM by Mario

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.

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker