Alex Rivera | Logout

Difference between member variable and member property?

Asked 2010-02-17T17:41:56.687
17

There are situations where I declare member variables at the top of my class and then also declare a property to access or set that member variable, but I ask myself if the property is necessary if it variable is only going to be accessed and set from within the class and no where else, so what is the advantage of using a property to access and set a member variable instead of just doing it directly to the member variable itself. Here is an example:

public class Car
{

    int speed; //Is this sufficient enough if Car will only set and get it.

    public Car(int initialSpeed)
    {
        speed = initialSpeed;
    }

    //Is this actually necessary, is it only for setting and getting the member
        //variable or does it add some benefit to it, such as caching and if so,
        //how does caching work with properties.
    public int Speed 
    {
        get{return speed;}
        set{speed = value;}
    }

        //Which is better?
        public void MultiplySpeed(int multiply)
        {
            speed = speed * multiply; //Line 1
            this.Speed = this.Speed * multiply; //Line 2

            //Change speed value many times
            speed = speed + speed + speed;
            speed = speed * speed;
            speed = speed / 3;
            speed = speed - 4;

        }
}

In the above, if I don't have the property Speed to set and get the variable speed, and I decide to change int speed to int spd, I will have to change speed to spd everywhere it is used, however, if I use a property such as Speed to set and get speed, I will just have to change speed to spd in the get and set of the property, so in my MutilplySpeed method, stuff like above this.Speed = this.Speed + this.Speed + this.Speed will not break.

c# oop
Edit
Report

2 Answers

1

The fact is, there is not a lot of difference between a publicly declared field and a public property with a private backing store if there is no extra logic. That being said, it is still considered best practice to use properties.

And before everybody jumps on me about extensibility, remember that if you do later need to add functionality, you can keep the name with the property and introduce a new name for the backing store so it's not a breaking change.

answered 2010-02-17T18:22:02.263
0

One thing you forgot to mention, properties will help you out when you extend your class. If your class is properly designed your variables inside the base class should be private. Without the actual properties public properties that is. You would have no way to access these private variables from within your extended class. We are talking public vs private and I am not including protected for a reason :).

Just some notes worth mentioning:

  • properties aide when a class is extended
  • properties to me make the code a bit more readable (in addition this.privateVariable verson PublicPropertyVariableName)
  • properties can ensure readonly, private sets, public gets etc (much more readable to other programmers). Consider a case where an IDentifier needs a public get but a private set
  • Personally to me too many gets / sets seems to complicate code, makes code less readable, too much extra unnecessary syntax
  • inheritance / extending to an extended class does not allow you to inherit private variables, properties are the answer. (again no mention of protected here, that is a different story)
  • To me even if the class has a private variable, my class methods still use the property to access or use that private variable
  • Don't forget about validation, it makes it much easier to validate especially readability wise.

These are just some common things (my 2 cents though on most of them).

answered 2010-02-17T17:45:05.493

Your Answer