Question

In all the examples I see, C# auto-implemented properties are made public, even in the MSDN documentation examples. Coming from a C++ background, I’ve always been taught that it is a good idea to make member data private, unless there is a good reason not to.

Why is the following never used (at least I’ve never seen it):

private Name { get; set; }

I’ve looked through the MSDN documentation and read several tutorials regarding auto-implemented properties but there does not seem to be any advice on their pros and cons and when they should be avoided. Do auto-implemented properties compromise program security? Are there situations where they should be avoided? In which situations are they the ideal choice?

Thanks.

Answer 1

You are correct that auto-implemented properties that simply expose a backing field are not much of a gain over a public field.

As Alan Kay said:

But most people who use setters simply use them to simulate direct assignments to interior variables, and this violates the spirit and intent of real OOP.

However, there is an advantage to an auto-implemented property over a public field, and that is that it’s a non-breaking change to later revise the implementation. If you have a public field, and code outside your class manipulates that public field, you can’t change it to a private field in a future version of the class, or else any other code that touches that field will have to be recompiled. By contrast, once you have a public property, you can revise the implementation of that property in a future version, and client classes can continue using it with zero changes.

So it’s useful to use auto-implemented properties for properties that right now would have trivial getter and setter implementations, but that may have more complex implementations in the future.