OO: Should you access your private variables through properties inside your class?

Question

I was wondering, what is good practice:

 private int value;

 public int Value { get { return this.value; } }

 private int DoSomething()
 {
      return this.Value + 1;
      //OR
      return this.value + 1;
 }

So, the question is about how you should treat your class variables. Should you access them through your properties or just direct?

Answer 1

I'd go for direct access. It's all "keeping it within the family", so to speak.

Answer 2

This is something that standards wars have been fought over. Usually it won't make a big difference and I settled on just accessing the variable directly from inside the class with the exception of getters and setters which do something beyond just getting or setting the value.

The catch is that you have to know what the getter and setting are doing, or you have to always limit them to the simple operation with no additional functionality.

Answer 3

In this case, it doesn't matter so much, but in cases where you're using lazy loaded variables it would matter and you'd access through your property. For instance:

private Myobject _value;

public Myobject Value
{
    get
    {
        if (_value == null) _value = new MyObject();
        return _value;
    }
}

private MyObject DoSomething();
{
    //If you access _value here, it might be null...
    //so you should access it through the property:
    return Value;
}

In a case where your method would fail by calling the field directly, you either handle it properly, or you access it by the cleaner method - via your property.

It all comes down to the architecture of your application and for that you have to ask the question: What makes the most sense from a maintenance perspective?

I would have to say that if the field is initialized properly and it doesn't cause you a headache to access it directly, then access it directly. If it causes extra work (and thus extra maintenance), then reference the property.

Like with anything else, weigh up the pros and cons. Use your own common sense - standards wars are a ridiculous distraction. Unless they provide you with arguments you haven't already thought of yourself, don't waste your breath fighting with them. If you have a valid reason to choose whichever path you choose, then that path is the right one - it comes down to the designer's prerogative.

My thoughts on pros and cons are this:

Going with property:

• I can change the implementation of how that value is returned without needing to refactor my whole class.
• I can lazy load the value which means that if I never access it, it never wastes resources.
• I can hide all the implementation details of how the value is returned in a single place without having to handle it all over my code.

Going with the field:

• I don't have the potential performance overhead of having to step through the property code each time I access the value.
• I need to make sure the value is initialized properly on every call, or handle cases where it is not.
• I can affect the value even though my property may only provide a read-only interface to my value.

So I guess my approach would be to use the property unless I needed to write to the value directly, in which case, I'd go with the field - as my property is read-only and thus can't be written to.

That's just me though - your property may be read/write and you may decide from a design standpoint that accessing the field directly is okay - and that is okay too.

The trick is always do things for a reason, don't do things blindly just because.

Answer 4

I vote for return this.value + 1.

The argument against this (ie going via the property) is that you might want to add extra code to your property method later, so there'd be less changes if you did that. But I'm of the mind that properties should just do as advertised and no more; that is, they should do just enough to return that value.

Answer 5

The properties are introduced to "hide" eventually more complex structure than returning a single value from a field.

I would advise that you use the property than the field in all your code, so if the property code changes later on to something more complex, you do not need to refactor the rest of the class.

Answer 6

In some situations it's a good idea. In the case of the iPhone, for example, given the low amount of memory, you might receive "memory warnings" from the OS. As per those warnings, you are asked to release memory to avoid being shut down. Usually, this memory comes from resources like images, sounds or big data chunks that you don't need continuously on memory.

In that case, I sometimes access some private ivars through Objective-C private accessors, which usually check if the ivar is "nil" (NULL), and will load the data back in memory, in a "lazy loading", ad-hoc way. For this I find private properties really useful. Otherwise, I use direct ivar access.

As always, I don't think there's a definitive answer to this question: "it depends".

Answer 7

If your class can't trust its own methods to access its own private variables, who can it trust?

Answer 8

I don't think it's a black and white question. A few things spring to mind:

Firstly, if the property has no behaviour (i.e. get/set just pass through to getting and returning a field), then make the field into an auto-property and remove the dilemma. Fewer lines of code, no confusion.

Secondly, if the property has side-effects (lazy loading, change notification, stats gathering etc.) then you must considered whether it is it appropriate to trigger that behaviour via private updates. If it is appropriate, just use the property. If it's not appropriate then don't (or change the design to make it more obvious).

Also, where appropriate you can always introduce a wrapper type to remove the confusion if it's very important.

E.g. say you had an Angle property that is protected by an argument check.

public class ManThatCanRotate
{
    public int Angle 
    { 
       get { return m_angle; } 
       set { if(value >= 0 && value < 360) m_angle = value; }
    }

    public void RotateLikeSomeKindOfLunatic()
    {
       // imagine this has been called 359 times already.
       m_angle++; // ruh-roh
    }
}

Bad things(tm) will happen if you set m_angle directly as above; the angle will become invalid. You can simply refactor the angle into its own type so that it is impossible to make invalid, thus removing the problem.