C# 3.0 auto-properties — useful or not? [closed]

Answer 1

In my opinion, you should always use auto-properties instead of public fields. That said, here's a compromise:

Start off with an internal field using the naming convention you'd use for a property. When you first either

• need access to the field from outside its assembly, or
• need to attach logic to a getter/setter

Do this:

1. rename the field
2. make it private
3. add a public property

Your client code won't need to change.

Someday, though, your system will grow and you'll decompose it into separate assemblies and multiple solutions. When that happens, any exposed fields will come back to haunt you because, as Jeff mentioned, changing a public field to a public property is a breaking API change.

Answer 2

I personally love auto-properties. What's wrong with saving the lines of code? If you want to do stuff in getters or setters, there's no problem to convert them to normal properties later on.

As you said you could use fields, and if you wanted to add logic to them later you'd convert them to properties. But this might present problems with any use of reflection (and possibly elsewhere?).

Also the properties allow you to set different access levels for the getter and setter which you can't do with a field.

I guess it's the same as the var keyword. A matter of personal preference.

Answer 3

It's simple, it's short and if you want to create a real implementation inside the property's body somewhere down the line, it won't break your type's external interface.

As simple as that.

Answer 4

We use them all the time in Stack Overflow.

You may also be interested in a discussion of Properties vs. Public Variables. IMHO that's really what this is a reaction to, and for that purpose, it's great.

Answer 5

The only problem I have with them is that they don't go far enough. The same release of the compiler that added automatic properties, added partial methods. Why they didnt put the two together is beyond me. A simple "partial On<PropertyName>Changed" would have made these things really really useful.

Answer 6

From Bjarne Stroustrup, creator of C++:

I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn't have been a class in the first place. It's just a data structure. And if it really is a data structure, make it a data structure.

And you know what? He's right. How often are you simply wrapping private fields in a get and set, without actually doing anything within the get/set, simply because it's the "object oriented" thing to do. This is Microsoft's solution to the problem; they're basically public fields that you can bind to.