Is shorthand version of properties compared to fileds the same

Is there any difference between these two classes from API/backward compatibility point of view:

Case A:

class Employee
{
    public string Title { get; set; }
}

Case B:

class Employee
{
    public string Title;
}

May I change from case B to case A without braking backward compatibility ?

Case C:

class Employee
{
    p开发者_JAVA百科ublic string Title { get { return T; } set { T = value; } }
    private string T;
}

May I change from case B to case C too without breaking backward compatibility ?

Switching between A and C is fine. From a public point of view they are identical. An automatic property is still a normal property. It just spares you the work of defining a getter, setter and backing field manually.

B is different from both of them since a field is not a property.

In particular reflection distinguishes them(listing properties vs listing fields). For example typical property editors or some serializers only list properties but not public fields.

And of course only the field can be passed around as ref or out parameter. So such code breaks when you switch to a property.

For normal code they are usually source compatible, but not binary compatible. i.e. if you change between field and property without recompiling a dependent assembly it will break. But if you recompile both it will work is most cases.

This means a public field is not that bad in application code(but I'd still avoid it), but for library code you should really use a property.

Case A and C are identical (in case A backing field is genreated automatically by compiler).

No you can't change from B to either A or C without breaking backward compatibility - as you are changing field to proerties.

No, generally you can't.

You for example can't pass references to properties, only to fields (you can't pass a value of property by reference). The are also differences if some of the code using the class used reflection.

They are not the same: B uses a public field, A uses a public property. If any of the consumers of your class uses reflection to get to the field or passes the public field by reference, they will break, same goes for C.

Your two examples are not the same. The following two are the same:

class Employee
{
    public string Title {get; set;}
}

and

class Employee
{
    private string _title;
    public string Title
    {
        get {return _title;}
        set {_title = value;}
    }
}

If you keep the names the same, then it shouldn't break backwards compatibility.

All the calls will be the same syntax-wise.

Problems may occur if you do it backwards. If you had a private variable and a property, the private variable may have been called in the class somewhere.

I want to make something clear that other people seem to be glossing over. While changing from B to C would not break a solution, this only works for things that are compiled together. If you are making an API or library which you want to reference in other projects and which you are not going to include in the solution (for example you are distributing the dll file to clients), changing from B to C will break clients using the API while changing from A to C will not.

Yes, you can, because you have declared the three classes private :-) :-)

Just kidding. Now... If you use StyleCop (or other similar "programs") they will mark all the public (and protected) (not-readonly nor const) fields as "bad things". This is because you can't change ANYTHING of them without breaking compatibility. The "right" thing to use a public field is not to use it, but to use a property (backed by a private field, or perhaps an internal field (but I'm not sure of this)). Now... A and C are "equivalent" against a "well behaved" user of the class (a "well behaved" user of the class uses only the public "interface" and doesn't use reflection).

To name a difference between A and B. You can pass ref and out of a field. You can't do it for a property (this is the "main" difference). The use of reflection on fields and property is different (it's OK to use public fields and properties through reflection)...