4

In terms of simple use, I perceive that Fields and Auto-Properties are functionally identical.

I'm aware of one case where they're substantially different: If you expose a property in a dll for a library and have other code using that dll, then (I believe?) you can change the property implementation, recompile the dll and replace the file, and the calling code doesn't need to be recompiled.

If what you exposed was a Field, then and change to "reimplement" that field as something more complex would require that the calling code be told about the change in some manner.

Another place where I repeatedly run into differences between Fields and Properties is in reflection-based libraries. E.g. CsvHelper or ServiceStack.Text, both of which will provide 'out-of-the-box' Serialisations, but which will only look at Properties, not Fields (as I just spent 2 hours realising :sad face: ). I think I had similar things with AutoMapper in the past too? It seems a relatively common thing.

It seems to me that I should therefore resolve to NEVER use a Field; that Properties are equal in the moajority of circumstances and VASTLY superior in others. The only downside is about 12 characters of extra "{get;set;}" in declarations.

Can anyone give counter-examples of either:

  • cases in general use where Fields are better than Properties?
  • libraries which rely on something being a Field NOT an Auto-property?

EDIT: Related but not identical: Public Fields versus Automatic Properties That seems to be a list of pros and cons, and I don't see ANY comments about advantages of fields, from a brief skim through. Feel free to post comments that are links to answers that I've missed in there.

Community
  • 1
  • 1
Brondahl
  • 7,402
  • 5
  • 45
  • 74
  • 1
    Normally fields aren't exposed unless they are `const`. Public constants are used commonly everywhere (fields are displayed differently by intellisense = great help when using them). Talking about private type variables you are very likely to start with private field. It will only become property if both are needed: original field value and converter/validated/whatever via property one. – Sinatr Jan 14 '16 at 15:04

4 Answers4

3

From the question which you linked, the first answer https://stackoverflow.com/a/1180870/3419534 highlights one specific place where fields can be used and properties cannot, and that is as ref parameters.

Consider:

int a;
int B { get; set; }
void F()
{
    a = 0;
    G(ref a); // a will be incremented
    B = 0;
    G(ref B); // Compiler error CS0206
}
void G(ref int p)
{
    ++p;
}
Community
  • 1
  • 1
ClickRick
  • 1,553
  • 2
  • 17
  • 37
  • You're right: I hadn't taken that away - I'd only taken the fact that WHEN you inevitably want a non-trivial implementation, THEN it becomes a breaking change (for reasons that might include `ref` passing) i.e. arguing that you should use Props from the get-go in order to avoid the breaking changes. Thanks for highlihgting this. – Brondahl Jan 14 '16 at 16:57
2

One thing you can do with fields that you can't do with properties is to access them ref. This includes use with Interlocked.CompareExchange().

As such, the code at https://stackoverflow.com/a/3871198/400547 wouldn't work if Node.Next wasn't a field.

Note though that it's in a private class. As a rule the benefits of properties over fields are such that when you do need a field you want it to be internal implementation details, not something publicly exposed.

Community
  • 1
  • 1
Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
1

Another case where I wouldn't use auto properties is static readonly fields when used as the "moral" equivalent of const fields where the type is not a primitive or string.

InBetween
  • 32,319
  • 3
  • 50
  • 90
1

You can make every question "not a duplicate" by inverting the question, but that doesn't change the fact that you're asking the wrong question. The actual question is "When would I use a public field on a class", to which the answer is: never. You never ever should use a public field. Ever. Really, there's no reason*.

MSDN: Generally*, you should use fields only for variables that have private or protected accessibility.

The reasons to use properties is explained in all questions linked to from this question, but mainly: encapsulation.

Sure, one thing you cannot do with properties that you can with fields is pass them by ref, but once you dive down that well all "best practices" can be ignored as well.

*: to be taken with a grain of salt. There are reasons, but you must really know what you're doing and why to go against all common advice.

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • You're right: The question you've suggested is identical to mine, but it's also not a duplicate of the one I linked to. The linked questions give plenty of reasons /cases where Props are better than Fields but I didn't perceive any of the reverse. – Brondahl Jan 14 '16 at 16:53
  • 1
    *Loved* the "once you [pass things by ref] all 'best practices can be ignored" bit, though :) +1 just for that. – Brondahl Jan 14 '16 at 16:54
  • Nowhere is "better" mentioned; all there are is differences. If you want to do something that you can't with a property: use a field. In all other cases, use a property. – CodeCaster Jan 14 '16 at 16:56