3

I am learning C# and i have encounter the following piece of code

public class Album
{
     public virtual int AlbumId { get; set; }
     public virtual int GenreId { get; set; }
     public virtual int ArtistId { get; set; }
     public virtual string Title { get; set; }
     public virtual decimal Price { get; set; }
     public virtual string AlbumArtUrl { get; set; }
     public virtual Genre Genre { get; set; }
     public virtual Artist Artist { get; set; }
}

just wondering what's the different with the following? i mean without the get and set you can access those public property as well. what's make it important to have those get and set?

public class Album
{
    public virtual int AlbumId;
    public virtual int GenreId;
    public virtual int ArtistId;
    public virtual string Title;
    public virtual decimal Price;
    public virtual string AlbumArtUrl;
    public virtual Genre Genre;
    public virtual Artist Artist;
}
falsetru
  • 357,413
  • 63
  • 732
  • 636
Bill
  • 17,872
  • 19
  • 83
  • 131

6 Answers6

2

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;
      }
    }
  ... 
}
Dmitry Bychenko
  • 180,369
  • 20
  • 160
  • 215
  • but does it makes any difference of setting properties and directly using values like classname.variablename??? – C Sharper Aug 06 '13 at 07:06
  • @M.N.S. http://stackoverflow.com/questions/295104/what-is-the-difference-between-a-field-and-a-property-in-c – MarcinJuraszek Aug 06 '13 at 07:07
  • @M.N.S: Technically, the syntax is the same, but there are some differences under the hood. For instance, in your very case (virtual property) you can override it in a derived class (see my edit). – Dmitry Bychenko Aug 06 '13 at 07:15
  • no-no,just forget about virtual and all, if albumid,etc are publically defined in public class, then through inheritance also we can directly access them like classname.variablename. Then why to use properties? any specific benifit??? – C Sharper Aug 06 '13 at 07:28
  • 1
    In general we use properties for restricting access (e.g. while get is public, set is protected or private); for complex output (get), e.g. if Title is null or empty, let's return AlbumId as 0; for validation (set), e.g. you can throw exception on attempts to set negative value to AlbumId; for interface implementation - you can put property into interface (property is a method(s)), but not field; for polymorphic behaviour - you can set property, but not field being vitual – Dmitry Bychenko Aug 06 '13 at 07:36
2

To have control over your object private fields values. for example if you don't wanna allow nulls or negative values for integers.

bool started;
    public bool Started
    {
        get { return started; }
        set
        {
            started = value;
            if (started)
                OnStarted(EventArgs.Empty);
        }

    }
another example

    int positiveNumber;

    public int PositiveNumber
    {
        get { return positiveNumber; }
        set {
            if (value < 0)
                positiveNumber = 0;
            else positiveNumber = value;
        }
    }

and also another implementation of read only properties could be as follows

   int positiveNumber;

    public int PositiveNumber
    {
        get { return positiveNumber; }

    }
backtrack
  • 7,996
  • 5
  • 52
  • 99
1

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.

Golo Roden
  • 140,679
  • 96
  • 298
  • 425
1

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.

Rune
  • 8,340
  • 3
  • 34
  • 47
1

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.

Ferit
  • 8,692
  • 8
  • 34
  • 59
1

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...!

Amin Saqi
  • 18,549
  • 7
  • 50
  • 70