What is the difference b/w public variable and public auto property

Question

Possible Duplicate:
Difference between Property and Field in C#

I know it is a very basic question but I cannot read any valid answer after searching

E.g

public string abc;

public string abc { get; set; }

Please describe this.

Answer 1

Variables store direct value but property are a window to your class and its variables.

Even though they work the same(almost), one very good thing with field is that if you want to do some extra work with field (like validation or doing any calculations) you can do so.

This will explain you

public string _abc;

public string abc 
{ 
  get
  {        
    return _abc;
  };

  set
  {
    if (value == null)
      _abc = "";
    else
      _abc = value;
  }; 
}

Here if null is passed to property abc then it will be checked it and an empty value will be assigned to _abc. otherwise value.

If we wanted this with a variable. every where we had to do this.

if(foo == null) // here foo is some string
    _abc = ""
else
    _abc = foo;

with property this can be done like abc = foo;

Now it will check for in the set section of property.

Answer 2

Properties can contain some code on setting/getting the value. Public variables can't and will not contain any code when you access them. This is a huge difference.

Using a property you're saying to whomever uses you're code that there might be some code behind the value now or in the future.

Using a public variable you're saying its just a boring old field that will contain some value.

Answer 3

One reason for using an auto property instead of a Field is compatibility.
For example, when you assign a field, the CLR does just that. It sets the field.
When you have a property (auto or not), and you type

someObject.Whatever = "Value";

it looks like you are assigning a field, but in reality, the C# compiler inserts something like this for you:

someObject.set_Whatever("Value");

That's not the same as setting a field. And if you have a field and change it to a property later (e.g. if you want to implement change notifications or things like that), you will have to recompile all assemblies that used the original field, since assigning a Field requires different code than setting a property (no matter if auto or not).

There is almost never a reason to use a public field. Automatic properties can be inlined at runtime, so there would be no performance difference. And they leave the possibility open to add additional logic to your get / set methods without having to recompile dependent assemblies.

Answer 4

(About my terminology: "field" = public variable, "property" = get/set)

One thing to be mentioned additionally to the differences in usage: A property, unlike a field, gets compiled to a method (I think it's called something like get_abc internally). Declaring an auto property from beginning on has therefor two advantages:

1) No problems with reflection. If some reflection code is based on the value being a field, and later you think "well, now I'd like to add null testing" and change to a property, then the reflection code will eventally fail (unless you expected that in the reflection, but that would be extra effort for nothing imho)

2) "Warning" of possible side effects. Fields can only change their values, methods can do arbitrary things to a class. So, declaring a property from beginning on signalizes the possibility of other changes happening in the background. (Of course one shouldn't do weird stuff in a setter, but sometimes it isn't impractical to get additional initialization from one value provided; e.g. measuring the length of a list)

I also would say that it's good style to use properties wherever possible. Especially for the two reasons provided, but also for consistency.

Answer 5

Same difference as a property over public variable such as property support binding but variable not.