Should I use public properties and private fields or public fields for data?

See this article http://blog.codinghorror.com/properties-vs-public-variables/

Specifically

Reflection works differently on variables vs. properties, so if you rely on reflection, it's easier to use all properties.

You can't databind against a variable.

Changing a variable to a property is a breaking change.

Three reasons:

You cannot override fields in subclasses like you can properties. You may eventually need a more complex getter or setter, but if it's a field, changing it would break the API. Convention. That's just the way it's done.

I'm sure there are more reasons that I'm just not thinking of.

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; }
}

This makes it as simple as creating a field, but without the breaking change issue (among other things).

When you create private field name and a simple public property Name that actually gets and sets the name field value

public string Name
{
   get { return name; }
}

and you use this property everywhere outside your class and some day you decide that the Name property of this class will actually refer to the lastName field (or that you want to return a string "My name: "+name), you simply change the code inside the property:

public string Name
{
   get { return lastName; //return "My name: "+name; }
}

If you were using public field name everywhere in the outside code then you would have to change name to lastName everywhere you used it.

Well it does make a difference. Public data can be changed without the object instance knowing about it. Using getters and setters the object is always aware that a change has been made.

Remember that encapsulating the data is only the first step towards a better structured design, it's not an end-goal in itself.

You have to use properties in the following cases:

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

It... depends?

I always use getters & setters, since they created this shortcut:

public int Foo { get; set; }

At compile time it is translated. Now you can't get fancy with it, but it is there, and if you need to get fancy you just spell it out later.

However public, private, protected... it's all a matter of who you want to be able to tweak the data. We use inheritance a lot and this is a very common method for us, so that only chidren can edit certain properties.

protected _foo;  
public Foo  
{  
    get { return _foo; }
} //lack of set intentional.

I can't believe that with 11 answers, nobody has said this:

Not all private fields should be exposed as public properties. You should certainly use properties for anything that needs to be non-private, but you should keep as much of your class private as possible.

There are many reasons why.

Mainly:

You can do some other functions when the variable is set

You can prevent setting and provide only get

Some 'things' only work on properties (DataBinding, for example)

You can hide the implementation of the property [perhaps it is a ViewState variable, in ASP.NET).

The point is - what if further down the line you want to make sure that every time myInt is referenced something special happens (a log file is written to, it's changed to 42 etc)? You can't do that without getters and setters. Sometimes it's wise to program for what you might need, not what you need right now.

Actually, if you're using Silverlight, you'll realise that fields cannot be set a static resources and thus you'll have to use a property (even to access a const).

I've realised that when I tried to federate the region names I use in Composite Guidance (PRISM).

However, that's just a language limitations and apart from static/const fields I alsways use properties.

The idea is you should not accidentally/unintentionally change the value of a class private field outside. When you use get and set, that means you are changing the class private field intentionally and knowingly.

Setting a value into a private field only changes that field,but making them in property you can handle another arguments for example,you can call a method after setting a value

private string _email;
public string Email
{
    get
    {
        return this._email;
    }
    set
    {
        this._email = value;
        ReplaceList(); //**
    }
}

In simpler words, answer to your question is the access modifiers i.e. public and private.

If you use:

public int myInt;
public int MyInt 
{
     get { return myInt; }
     set { myInt = value }
}

then both MyInt property and myInt variable is available in the project to be modified. Means, if your class suppose A is inherited by class suppose B, then myInt and MyInt both are available for modification and no check can be applied. Suppose you want myInt value can be set in derive class if some particular condition pass.

This can be achieved only by making field private and property to be public. So that only property is available and conditions can be set based on that.