C#: Public fields vs automatic properties
An interesting new feature in C# 3.0 is that of automatic properties on objects – this allows us to define a get/set property and the creation of the underlying field is taken care off for us.
We can therefore create a class like this:
public class Foo { public string Bar { get; set; } }
Now ignoring the fact that it's terrible OO to write a class like that, one thing that we've been wondering is what's the difference between doing the above and just creating a public field on Foo called Bar like so:
public class Foo { public string Bar; }
In terms of how we use the class in our code it's conceptually the same but there are a couple of subtle differences.
We can change our implementation more easily if we use the automated properties. If we decide that we want to do something else apart from just setting a field or returning it then we can do that more easily without having to recompile assemblies that depend on that class.
If we decided we only wanted the getter to be public but to have a private setter that would be an easier change using automated properties, and if we want to reflect on the class I find it's much easier to do that when we have properties rather than fields.
That's all I can think of at least. Are there any other differences?
Hi,
How come it's terrible OO?
Ben
4 Feb 09 at 7:30 pm
One issue with using public fields is that you may end up with problems, should you decide to change it to a property (automatic or not). A change from a public field to a property is not binary compatible (the IL used to access the field is different from the IL used for accessing the property).
If you only have source dependencies, this is not an issue, though.
Jesper Kamstrup Linnet
4 Feb 09 at 8:03 pm
I've run into code that only inspects public properties when it wants to visit the significant pieces of state in an object – might be something to test if you are using any sort of 3rd party mapping framework.
Scott Allen
5 Feb 09 at 1:45 am
[...] C#: Public Fields vs Automatic Properties (Mark Needham) [...]
Dew Drop - February 4, 2009 | Alvin Ashcraft's Morning Dew
5 Feb 09 at 2:59 am
One issue with public fields is that you cannot add code to getter or setter methods properties if you decide to change it later and if you change a filed to a property later that might affect the code that uses that class. If you are using some thing like reflection that is.
However automatic properties will let you change the autmatic property into a normal property at later part of the development without changign the contract or in other words changing the code.
Shafqat Ahmed
5 Feb 09 at 3:35 am
Jesper's IL comments are on the mark. This can be an impact when using atributes to tag the code – attributes that work with methods may be different from filed attributes. For example, see Castle ActiveRecord attributes.
Curtis Olson
5 Feb 09 at 5:14 am
Field and properties are also treated differently at the level of reflection; there isn't one method on Type that will return both fields AND properties (other than GetMemberInfo I expect, which will return events and methods as well).
So going down the the automatic property route may deal with reflection difficulties (eg. NHibernate or your own serialisation framework may only handle properties perhaps?)
James Webster
5 Feb 09 at 6:29 am
Just to clarify something, automatic properties are the same as standard properties as far as reflection is concerned; automatic properties are just syntactic sugar and produce the same IL as regular properties.
James Gregory
5 Feb 09 at 9:31 am
[...] C#: Public fields vs automatic properties – Mark Needham talks briefly about the differences between fields and automatic properties. Some good comments on this post too [...]
Reflective Perspective - Chris Alcock » The Morning Brew #280
5 Feb 09 at 6:20 pm
You can also use
public string Bar { get; private set; }
And when you later want to implement extra logic it won't break IL code that references the property.
Steve
5 Feb 09 at 8:12 pm
Only properties, automatic or regular, work with things like data binding in WinForms and WPF.
Jason Kemp
5 Feb 09 at 11:21 pm
The other difference as of now is that we can't initialize automatic properties with values – the opposite is true with public fields. I believe in the .NET 4 the are gonna allow initializing automatic properties. And one of the other difference is in usage by various serialization formatters, such as the default XML serializer does not automatically serialize public fields. And lastly, a number of useful attributes are normally not allowable on fields.
Rishi
6 Feb 09 at 11:18 pm
You can't use INotifyPropertyChanged on a public field.
Stuart
7 Feb 09 at 8:37 am
public class Rect
{
public int Width {get;set;}
public int Height {get;set;}
}
public class A
{
public Rect Rect {get;set;}
}
….
A obj = new A();
// can't do this in C#
// (you could if Rect was a public data member)
a.Rect.Width = 10;
L
20 Apr 09 at 8:11 am
Sorry – I meant "public struct Rect" in the previous example.
L
20 Apr 09 at 8:40 am
Properties can be included in an interface, fields cannot.
Matthijs
12 Jan 10 at 12:36 pm