Windows Develop Bookmark and Share   
 index > Windows Forms General > Automatic properties versus public fields
 

Automatic properties versus public fields

One thing I have never understood is the reason for the preference of public properties that set private fields versus public fields, and especially when it comes to automatic properties.

I know that public fields are forwned upon, but functionally, aren't they the very same?

static public string MyField { get; set; }

versus

static public string MyField;

or


static private string MyField_Prv ;

static public string MyField {
     get { return MyField_Prv ; }
     set { MyField_Prv = value; }
Functionaly, they all seem to work the very same from outside the class, but to use a public field seems to badly regarded, even though it isless typing.

There has to be something I am not thinking of.
JimGuyer  Wednesday, September 09, 2009 6:39 PM
The issue is encapsulation.

Data protection and encapsulation is a standard OOP principle. The issue here isn't whether you can, it's whether you should. By using an automatic property, you're creating a "stub" whereby you can add logic, if you need to.

Also, using public fields can wreak havoc on other things.... for example, what if you were to use reflection on your class (where you get and set properties based on metadata) and you had previously used a field? Well, you'd have to change that code.

Also, you can't databind to a field. You have to data bind to a property.

There's several posts out there on the internet, some that would argue for the use of fields over properties, and several that would argue the other way around.

Personally, I think it's worth using properties simply to stick to convention. The convention is to wrap a private field in a public property. Everyone understands that, so I should stick to it to avoid confusing people.

Performance-wise, simple properties do the exact same thing as public fields, as the call is optimized out by the JIT compiler.

I'd stick to the convention.
Coding Light - Illuminated Ideas and Algorithms in Software
Coding Light Wiki �LinkedIn �ForumsBrowser
  • Marked As Answer byJimGuyer Wednesday, September 09, 2009 6:57 PM
  •  
David M Morton  Wednesday, September 09, 2009 6:46 PM
The issue is encapsulation.

Data protection and encapsulation is a standard OOP principle. The issue here isn't whether you can, it's whether you should. By using an automatic property, you're creating a "stub" whereby you can add logic, if you need to.

Also, using public fields can wreak havoc on other things.... for example, what if you were to use reflection on your class (where you get and set properties based on metadata) and you had previously used a field? Well, you'd have to change that code.

Also, you can't databind to a field. You have to data bind to a property.

There's several posts out there on the internet, some that would argue for the use of fields over properties, and several that would argue the other way around.

Personally, I think it's worth using properties simply to stick to convention. The convention is to wrap a private field in a public property. Everyone understands that, so I should stick to it to avoid confusing people.

Performance-wise, simple properties do the exact same thing as public fields, as the call is optimized out by the JIT compiler.

I'd stick to the convention.
Coding Light - Illuminated Ideas and Algorithms in Software
Coding Light Wiki �LinkedIn �ForumsBrowser
  • Marked As Answer byJimGuyer Wednesday, September 09, 2009 6:57 PM
  •  
David M Morton  Wednesday, September 09, 2009 6:46 PM
Excellent. Thank-you.
JimGuyer  Wednesday, September 09, 2009 6:58 PM

You can use google to search for other answers

Custom Search

More Threads

• How to indent active buttons???
• Converting IDL to C#
• CheckBox.Text...text is misaligned?
• Am I connected to the Internet?
• restricting form resize using framework 1.1
• Disabled Button Controls
• Changing the HEIGHT of a DateTimePicker
• Displaying a table in a pop-up form
• Change controls from inherited form??
• Windows Schedular