Public readonly field v.s. get-only property

Question

Are there cases when you would want a public readonly field v.s. a get-only auto-implemented property?

public class Foo
{
    public readonly string Hello;

    public string Hello2 { get; }
}

Both can only be set during the constructor and both offer readonly access outside of the class.. I'm a little tired so I might be missing something.

score 37 · Answer 1 · answered Oct 14 '16 at 09:14

37

Making it a property rather than a field means it can be used on interfaces.

The exact implementation (although auto-properties don't really have much implementation...) is also abstracted, so you could in the future base it on a combination of fields without breaking (compile) compatibility.

answered Oct 14 '16 at 09:14

pete the pagan-gerbil

3,136
2
28
49

Great example thanks, I knew there was something obvious I was missing here. The context I was wondering about was the Startup.cs in the default asp.net core template, interestingly Startup doesn't implement an interface, but perhaps the property is used as a hook elsewhere. – Alex KeySmith Oct 14 '16 at 09:18
5

I really want to mark your's and PaulF's as the answer, as they both make sense his was slightly sooner, but if I could I'd mark yours as well! – Alex KeySmith Oct 14 '16 at 09:23

score 20 · Accepted Answer · edited May 23 '17 at 12:32

20

One reason would be for data binding - .net implements binding to properties but not to public fields.

Some discussion here : Why can't we use public fields for data binding in C#?

edited May 23 '17 at 12:32

Community

1
1

answered Oct 14 '16 at 09:08

PaulF

6,673
2
18
29

Public readonly field v.s. get-only property

2 Answers2

Linked

Related