C# basic property understanding

You can't declare a virtual field

public class Album { public virtual int AlbumId; // <- Syntax error ... } 

properties are, in fact, methods: get or(and) set, so

public class Album { public virtual int AlbumId { get; set; } // <- Both get and set methods declared as virtual ones ... } 

And you can override these get's or(and) set's in derived class if you want:

public class GreatAlbum: Album { private Boolean m_IsGreat; public override int AlbumId { get { if (m_IsGreat) return base.AlbumId else return 0; } set { m_IsGreat = (value != 0); base.AlbumId = value; } } ... } 

With providing get(accessor) and set(mutator) methods, you can control accessing and mutating. For example:

You have a property that you don't want to be set any value more than 15. So u make required restrictions in your set method. Unless that set method, you can't control.

But in your example, your get and set methods are default, means controlling nothing.

The main reason behind properties is to protecting and presenting private data in a controlled way.

In fact, properties show their abilties in the usage like this:

public virtual int AlbumId { get { // ... some magical operations ... } set { // ... some magical operations ... } } 

And about your main question - what's the difference in this example - the main point to attention is the virtual keyword.

This keyword causes the property to be overrideable, So any other code could override the default get; method. It meens that you have the default behavior for yourself, and other codes (Extremely used in Entity Framework) implement their own logic!

Those second ones in your example aren't properties, so they don't express this magical ability...!

In the first case you are dealing with properties, in the second with fields.

Using fields has several drawbacks when compared to using properties. These drawbacks include:

1. You can set a breakpoint in a get or set of a property, but you can not set a breakpoint on access to the field.
2. Making fields public violates the information hiding principle.
3. The binary MSIL code for accessing fields and properties is different, so if you change a public field to a public property in the future, although the source code stays compatible, any dependant binary code breaks.
4. The code required to use reflection is different, hence when you move from a field to a property, your reflection code will break.

To cut a long story short: Always use public properties, NEVER use public fields.

There are a number of differences:

• Properties are turned into methods by the compiler. As such, you can declare them virtual and override them in a derived class.
• Using properties, you can put logic in the getter or setter (filtering, validation etc).
• When you use automatically implemented properties ({ get;set;}), it may seem that you might as well just use public fields. However, using properties means you can change your getter or setter implementation at a later time, without changing the interface your class is exposing. If you had used a field and wanted to implement filtering whenever that field was read, you would have to introduce a new method, make the field private and break all existing consumers of the type.

Personally, I think the automatically implemented properties promote bad style, because they do not encourage encapsulation. Tools like ReSharper also like to generate properties with {get;set} accessors. Novice developers thus typically end up with classes with lots of {get;set;} properties exposing the type's state to the world. You should at least use {get; private set;} by default.