0

I know the benefits of using properties: bigger flexibility, easier changes, more convenient than methods, you can use them in interfaces etc. There are so many advantages that I never use fields (only automatic properties) and at this point I wonder if I'm doing right. Maybe there are some situation where instead of

private int Variable { get; set; }

I should use

private int variable;

Even when I don't need it to be a property, I use automatic properties in case it would change and then it will be to late to change it painlessly.

wozar
  • 15
  • 2
  • 1
    Since in your example above, the property is `private`, a better question might be is there any reason to use a property when it's marked private? https://stackoverflow.com/questions/3310186/are-there-any-reasons-to-use-private-properties-in-c discusses this – ADyson May 23 '19 at 14:03
  • Mark as duplicate https://stackoverflow.com/questions/1180860/public-fields-versus-automatic-properties – SUNIL DHAPPADHULE May 23 '19 at 14:07
  • @ADyson No, these are arguments for using properties over fields. I wonder if there's opposite situation when you should use field over property. As now I use properties for everything and never use fields and I wonder is it ok. – wozar May 23 '19 at 14:29
  • @SunilDhappadhule see above please – wozar May 23 '19 at 14:30
  • @wozar I'd say that (by simple logical deduction) it's fine to use fields in any situations not mentioned as a scenario where you ought to use a property. The thing with fields is, they're just variables which happen to be attached to a class, rather than declared in a method. Unlike properties they don't really have any interesting extra features where you could make a positive case that it'd be an advantage. IMO you can just assume you could/should use them anytime that it wouldn't be a disadvantage to not use a property. – ADyson May 23 '19 at 14:33
  • 1
    If you are using (non-constant) properties, you are *also* always using fields, albeit fields the compiler generates for you. There have been scenarios in the past where you were required to make a field explicit (because you needed to apply an attribute to them, or because you needed to initialize a readonly field lazily) but there has been a steady introduction of syntax to make this unnecessary. It is still worth keeping in mind that for some scenarios (as in serialization or other low-level bit groveling) only the fields may be considered and not the properties. – Jeroen Mostert May 23 '19 at 14:38
  • @wozar a property is a function it can be overridden, hide and apply polymorphy to it. Only thing is you can not use for "ref" or "out" parameter – SUNIL DHAPPADHULE May 23 '19 at 14:42
  • @ADyson So using properties in any situation, as I do now, is perfectly fine. Good to know. Thank you very much for your help – wozar May 23 '19 at 14:47
  • `ref`/`out` is a good point -- an important thing you cannot do with a property is use it as an argument to `Interlocked.CompareExchange` and other atomic primitives that need `ref` parameters. These are fairly niche uses, but important ones. On the other hand, they're also easy to spot. – Jeroen Mostert May 23 '19 at 14:47
  • @SunilDhappadhule Yes, this is worth keeping in mind. I also noticed if type of your property is struct you can't change just one field - you have to assign a new struct (because `get` returns a copy of value type variable) – wozar May 23 '19 at 14:50
  • @JeroenMostert Thank you for pointing that case. I hope I will remember this when I will be advanced enough to understand case you mentioned :) – wozar May 23 '19 at 14:52
  • @wozar one more thing about property is you can inject dependency through a property – SUNIL DHAPPADHULE May 23 '19 at 14:56

0 Answers0