Why do we use fields & properties instead of just a variable?

Just for encapsulation principle. For hiding concrete implementation, and plus, you have an opportunity (in this case) to add additional code inside get/set.
If you don't need additional code, you can use just

public string Name{get; set;}

or use fields, as you would like. But using properties is a guideline offered by Microsoft.
So basically all, follow it.

There are valid reasons to make a trivial property:
1) Reflection works differently on variables vs. properties, so if you rely on reflection, it's easier to use all properties.
2) You can't databind against a variable.
3) Changing a variable to a property is a breaking change.
4) a property can be easily bound to a control or other reflection-based controls that read all properties (rather than fields).
5) there may be actions that you want to perform in getters or setters (such as firing a NotifyPropertyChanged event).

Mark This Response as Answer
--
Chandu
http://www.dotnetfunda.com/images/dnfmvp.gif

krrishbiju-15589, if this helps please login to Mark As Answer. | Alert Moderator

Dear Krrish,

Three reasons:
1. You cannot override fields in subclasses like you can properties.
2. You may eventually need a more complex getter or setter, but if it's a field, changing it would break the API.
3. Convention. That's just the way it's done.
4. In .Net 3.x you can use automatic properties like this:

public int Age { get; set; }

Instead of the old school way with declaring your private fields yourself like this:

private int age;



public int Age

{

    get { return age; }

    set { age = value; }

}

Happy Coding.

If it helps you or directs U towards the solution, MARK IT AS ANSWER

krrishbiju-15589, if this helps please login to Mark As Answer. | Alert Moderator

Dear Krrish,

You have to use properties in the following cases:
1. When you need to serialize data in the property to some format.
2. When you need to override properties in derived class.
3. When you implement get and set methods with some logic. For example, when you implement Singleton pattern.
4. When you're derived from interface, where property was declared.
5. When you have specific issues related to Reflection.

Happy Coding.

If it helps you or directs U towards the solution, MARK IT AS ANSWER

krrishbiju-15589, if this helps please login to Mark As Answer. | Alert Moderator

Dear Krrish,

Here are many reasons why.
Mainly:
1. You can do some other functions when the variable is set
2. You can prevent setting and provide only get
3. Some 'things' only work on properties (DataBinding, for example)
4. You can hide the implementation of the property [perhaps it is a ViewState variable, in ASP.NET).

Happy Coding.

If it helps you or directs U towards the solution, MARK IT AS ANSWER

krrishbiju-15589, if this helps please login to Mark As Answer. | Alert Moderator

Hey...The idea is to manage the values inside of the object, state, avoiding corruption and misuse by calling code.

A property gives you several advantages over a simple public field:

- you can control whether the property is read-only, write-only, or read/write
- you can hide the actual implementation (maybe in the setter you want to do more than just setting a value)
- when using databinding (e.g. in ASP.NET), you'll have to use properties (does not work with fields)

krrishbiju-15589, if this helps please login to Mark As Answer. | Alert Moderator

Hi,

The main advantage is that you can attach all sorts of functionality to a property such as validation, synchronization etc. You can't do that for a plain class member. A variable can't throw an exception if you try and assign a value that does not make sense with your biz logic, for example. Also imagine trying to protect a variable for thread synch. You have to write extra code in other places to do that while with a property you can simply wrap the getter and setter with a lock in one place.

Now, you might think that validation and synchronization are not important to you for this particular value, and they may never be for this particular instance. But the thing you're doing by using properties instead of direct variable access is making your application much more maintainable in the future.

Also, for managing information shared across many classes (global) take a look at the singleton pattern. Though beware, even though it looks neat and clean you can still get into trouble with it. But if you really need global data you should not just use properties but a singleton class to organize them as well.

Mark as answer if satisfied....

Regards,
Shree M.

Kavya Shree Mandapalli

krrishbiju-15589, if this helps please login to Mark As Answer. | Alert Moderator