When inside a class, is it better to call its private members or its public properties?

Question

This is something that I've always wrestled with in my code. Suppose we have the following code:

public class MyClass {
    private string _myVariable;

    public string MyVariable {
        get { return _myVariable; }
        set { _myVariable = value; }
    }

    public void MyMethod() {
        string usingPrivateMember = _myVariable; // method A
        string usingPublicProperty = MyVariable; // method B
    }
}

Which way is more correct - method A or B? I am always torn about this. Method A seems like it would be minutely faster, due to the fact that it doesn't have to go access a property before getting the real variable. However, method B is safer because if the getter for MyVariable gets business logic added to it, you are safe by always calling it, even if there is no current business logic.

What's the general consensus?

Answer 1

This would really depend on what you are accessing the property for. Consider the following two scenarios:

Scenario 1: you write a method to provide a common action on the data in the class:

// assume a hypothetical class Position

public class Circle
{
    private int _radius;
    private int _xpos;
    private int _ypos;

    public int Radius { get { return _radius; } }
    public Position Center { get { return new Position(_xpos, _ypos); } }

    public bool PointInCircle(Position other)
    {
         return distance(this.Center, other) < this.Radius;
    }
}

Clearly the behavior of PointInCircle should be the same as if the user executed the code inside it. Therefore, it makes sense to use the public properties.

Scenario 2: you write a method to manipulate the underlying data. A good example of this is serialization. You would want to serialize the underlying data members as opposed to the values returned by property accessors.

Answer 2

depends, if you access the property, there might be 'validation' code that is called.

private int timeSinceLastPropertyAccess;

public int TimeSinceLastPropertyAccess
{
   get 
   { 
      // Reset timeSinceLastPropertyAccess to 0
      int a = timeSinceLastPropertyAccess; 
      timeSinceLastPropertyAccess = 0; 
      return a; 
   }
}

Do you want timeSinceLastPropertyAccess to be reset when it is used when inside your class or not?

Answer 3

Use the property.

I think the property should be wholly responsible for managing that field.

There are plenty of implementations where it won't matter, but there are lots where it does matter -- a lot. Plus, this can be a bit of a pain to track down, because it always looks right.

You'll go wrong calling the property far fewer times than calling the field, and where there are exceptions to this rule, document the rationale.

Answer 4

Just to add one more thing, your example only asked about getters. The other half of this is setters.

Sometimes you will want the object to use the setters and sometimes you would want it to bypass them and just assign the underlying field.

For example, let's say you have a property called IsModified. Which would tell you whenever the object has been modified. You could have all of your setters flip this to true in the event a different value is assigned to one of the underlying fields.

Now if you are hydrating that object (either loading from a db or somewhere else) then you wouldn't want IsModified set. Because, quite frankly, it isn't modified yet. So in that method you use the underlying field names, but in all of the other methods you use the property setter.

Answer 5

it depends, do you want to do what the property does? private/public doesn't really matter, its just like calling a function.

as it is, you have really just set up a "function" in anticipation of having to do something whenever that value is accessed or changed.

the problem with doing this is you might come to find you want to do one thing where its accessed in some places, and another when its accessed in other places, so you are still going to have to change all the 'calls' to it in one of the places.

fact of the matter is, if EVERYTHING that access that variable - even the private class functions - does so through the property that just passes through the variable, why bother having the property at all? why not just create the variable called 'MyVariable' then if you find you wanna do something when its changed/accessed, just create another variable called _MyVariable or something, then change MyVariable to be a property for _MyVariable then.

you should think of properties as being just like the accessor() and mutator() functions you used to write, the trick with them was, if you found that you DID want to do some code whenever a variable was 'accessed' you had to change ALL the calls to that variable to use an accessor instead (calling a function, rather than just accessing a member variable), that is why you would create 'default' accessors and matadors, just in case. As I have stated above, you don't have that problem with c# and properties (except in one lame case where you can't write to the sub members of a member if its a property... WHY??)