C# autoproperty vs normal fields

Question

is there any effective difference between Foo.Something and Bar.Something in this example?

class Foo
{
    public string Something;
}

class Bar
{
    public string Something{get; set;}
}

class Program
{
    static void Main(string[] args)
    {
        var MyFoo = new Foo();
        MyFoo.Something = "Hello: foo";
        System.Console.WriteLine(MyFoo.Something);

        var MyBar = new Bar();
        MyBar.Something = "Hello: bar";
        System.Console.WriteLine(MyBar.Something);
        System.Console.ReadLine();
    }
}

AFAIK they behave exactly the same. If they do why not to use plain Fields like in Foo? In java we use setters to be able enforce new invariants without breaking code and getters to return safe data but in c# you can always rewrite Foo into this:

class Foo
{
    private string _Something;
    public string Something
    {
        get { 
            //logic
            return _Something; 
            }
        set { 
            //check new invariant
            _Something = value; 
            }
    }
}

And old code will not be broken.

Jon Skeet · Accepted Answer · 2013-03-21T15:17:55.740

11

AFAIK they behave exactly the same.

No they don't.

Fields can't be used in data binding (at least in some binding implementations)
You can add more logic later for properties without breaking source or binary compatibility
Properties can't be passed by reference
You can't add an initializer to an automatically implemented property
They'll clearly be different in terms of reflection
Philosophically, properties are logically part of the API whereas fields are an implementation detail

in c# you can always rewrite Foo into this: [...]

Well you can if you don't care about binary or source compatibility, yes. In some cases that's really not an issue - in other cases it's very, very much an issue. Why not make the choice to expose your API rather than your implementation details from the start? It's not like adding { get; set; } in your code is adding much clutter...

For more ranting, see my article on this.

edited Mar 21 '13 at 15:17

answered Mar 21 '13 at 15:01

Jon Skeet

1,261,211
792
8,724
8,929

1

And auto-properties can't have (the equivalent of) field initializers. For example if you want `Something = "initial"` initially, with the property you will have to make your instance constructor explicit and write the assignment in the body of that constructor (or all constructors unless they "chain" each other with the `: this(...)` syntax). – Jeppe Stig Nielsen Mar 21 '13 at 15:15
Jon Skeet walks into a question, 4 upvotes. – EaterOfCode Mar 21 '13 at 15:16
@JeppeStigNielsen: True, true. – Jon Skeet Mar 21 '13 at 15:17
1

@EaterOfCorpses Which is largely irrelevant to him, as he's already well past the rep cap for the day anyway. – Servy Mar 21 '13 at 15:28

Botz3000 · Answer 2 · 2013-03-21T15:05:38.760

Foo.Something is a field, Bar.Something is an automatically implemented property. That's a huge difference.

You can just access properties the same way as fields, but internally a set/get method is called when you access a property.

So when you say myBar.Something = "asdf", the C# compiler translates this to a call to a setter method: myBar.set_Something("asdf"). The setter and getter methods are generated automatically for you, as well as a backing field for the actual value.

By changing Foo.Something to a property with get and set methods, you are breaking binary compatibility, that means you'll have to recompile all assemblies that used Foo.Something when it still was a field.

score 0 · Answer 3 · answered Mar 21 '13 at 15:00

0

The getters and setters of a property (including automatic ones) have a method call cost. Public fields should be avoided in order to keep things clean with access.

answered Mar 21 '13 at 15:00

Daniel A. White

174,715
42
343
413

You: _Public fields should be avoided_ I guess public **`readonly`** fields are alright? The BCL uses them. Of course this is not relevant to the original question. – Jeppe Stig Nielsen Mar 21 '13 at 15:07
@JeppeStigNielsen i guess so. – Daniel A. White Mar 21 '13 at 15:08
1

@JeppeStigNielsen: The BCL rarely uses readonly *instance* fields. Constants (even non-const constants, if you see what I mean) are a different matter. – Jon Skeet Mar 21 '13 at 15:18
@JonSkeet I guess you're right. For example `KeyValuePair` doesn't use `readonly` instance fields, it uses `get`-only instance properties (no `private` setters found by reflection, though). – Jeppe Stig Nielsen Mar 21 '13 at 15:31

Jacek · Answer 4 · 2013-03-21T15:08:54.363

0

1) You can add private accessor to get or set and control access to property.

public object MyProp {get; private set;}

You can read prop everywhere, but write only inside class

2) You can connect some logic to read/write property. In case of field you can not do anything additional

3) You can not serialize fields

edited Mar 21 '13 at 15:08

answered Mar 21 '13 at 15:01

Jacek

10,507
21
58
108

You can also do this with usual properties. – Carsten Mar 21 '13 at 15:04
@Aschratt Yes, but with a field you can't. You may specify `readonly` with a field, of course, but that is somewhat stricter than a `private` setter. – Jeppe Stig Nielsen Mar 21 '13 at 15:05
Sorry, I thought the question is about the difference between standard-properties and auto-properties... :) No harm meant! – Carsten Mar 21 '13 at 15:11

score 0 · Answer 5 · answered Mar 21 '13 at 15:01

0

public string Something{get; set;} is just syntactic sugar; the compiler actually expands this to methods. So there is little point in having all get; set; fields all over the place, just for the sake of it.

answered Mar 21 '13 at 15:01

David S.

5,523
1
34
68

C# autoproperty vs normal fields

5 Answers5