New automatic properties in c# 3.0, what's the benefit?

Question

Hi,

Whats the benefit of:

public string User {get; set;}

over

public string User;

Since you can't access the private member in the first case, how is it any different that just making your property public?

Answer 1

you will find some answers here.

http://stackoverflow.com/questions/174198/c35-automatic-properties-why-not-access-the-field-directly

Answer 2

This is a duplicated question. See here.

Answer 3

The second example is making the field public, not a property (your question). This provides a simple way of making simple properties. Properties should be your default, not public fields; the list of reasons is endless, but starts with:

• encapsulation
• ability to add notification
• encapsulation
• ability to do validation
• encapsulation
• data binding
• encapsulation
• security checking

oh - and did I mention encapsulation?

Changing from a field to a property after-the-fact is a breaking change - especially if you use a lot of "ref" code or mutable structs (yeuch).

Answer 4

There can be a number of things that you must do when User value changes. Things that you don't know in advance or are not present at the time you design your classes. For example one day you realize that user value should be at least 5 characters long. If you have and property it simple to implement. If you have a public field you must change that to property and recompile all dependent code.

In essence I think it pays to explicitly separate public/API part of the our types and the private implementation details.

Did someone mentioned encapsulation ? ;)