Mark Needham

Thoughts on Software Development

C#: Public fields vs automatic properties

with 16 comments

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?

Written by Mark Needham

February 4th, 2009 at 5:52 pm

Posted in .NET

Tagged with ,

«
»
  • http://n/a Ben

    Hi,

    How come it’s terrible OO?

  • http://blog.kamstrup-linnet.dk Jesper Kamstrup Linnet

    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.

  • http://www.OdeToCode.com/blogs/scott/ Scott Allen

    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.

  • Pingback: Dew Drop - February 4, 2009 | Alvin Ashcraft's Morning Dew

  • http://www.shafqatahmed.com Shafqat Ahmed

    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.

  • Curtis Olson

    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.

  • http://www.thenewsbeforethenews.com James Webster

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

  • http://jagregory.com James Gregory

    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.

  • Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #280

  • Steve

    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.

  • http://www.ageektrapped.com Jason Kemp

    Only properties, automatic or regular, work with things like data binding in WinForms and WPF.

  • http://www.orkpad.com Rishi

    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.

  • Stuart

    You can’t use INotifyPropertyChanged on a public field.

  • L

    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

    Sorry – I meant “public struct Rect” in the previous example.

  • Matthijs

    Properties can be included in an interface, fields cannot.