A debate came up at work, recently, that went around in circles with no resolution.

When a class provides a public interface to a property, and it uses that value in other work inside the class, should it access that value through the public property, or the private implementation?

For example, in the C# code below:

 public class Demo {

  private int miles;
  public int Miles {
     get {
        return miles;
     }
     set {
        miles = value;
     }
  }

  public string How''''''Far() {
     if( what == 0 ) {
        return "Right here";
     }
     else if( what < 10 ) {
        return "Near";
     }
     else {
        return "Far";
     }
  }
 }

...what should the method How''''''Far() have in the spots labelled 'what'?  The private variable miles, or the public property Miles?  Do both approaches have advantages?

To add to the irony of the situation, both camps in the debate claimed that their own approach was the one that showed good encapsulation.

I'm dissatisfied with this page name, but not finding a better one...

-----

I'd say use the public accessors.  Think about what's likely to change and how much you'll have to fix if it does change.  The public interface is relatively stable; if it ''does'' change then updating the other methods of the class is the least of your worries, and so you aren't creating appreciable extra work.  The private implementation, however, is supposed to be fairly mutable.  Why else would you make it private in the first place?  If you reference it in multiple methods, you have to change each of those methods.  Might as well save yourself some effort and implement the changes OnceAndOnlyOnce.

I've actually saved a fairly significant amount on time on programming projects by doing this.  Oftentimes, a property that I thought was going to be a simple get/setter ended up computing and caching results, or suddenly needed thread safety, and if I'd used it in 20 places within the class I'd have to change 20 places.  In this case, I needed a public accessor anyway, so might as well use it and have my changes propagate automatically to the rest of the code.

(Note that this assumes you're depending on the property and not any specific implementation of the property.  I can see cases where there'd be exceptions - for example, using a thread-safe accessor in a performance-constrained inner loop vs. using the field itself and adding synchronized blocks or mutexes around the loop itself.  But I suspect that most times you'll end up saving effort by using the accessor.)

-JonathanTang

-----
There are effects on subclasses, as well.  See "A Study of the Fragile Base Class Problem",  Mikhajlov and Sekerinski, http://www.cas.mcmaster.ca/~emil/publications/fragile/ 

-----

How about: AvoidDirectAccessOfMembers, AccessorsAreEvil, ShouldMemberVariablesBeAccessibleToDerivedClasses, ForgetAboutWritingAccessors, or UniformAccessPrinciple?

----

Well, since you asked:

AvoidDirectAccessOfMembers:  I combed the wiki for anything in one direction or the other, but missed this page.  Thanks, it's directly on topic.

AccessorsAreEvil:  Is an interesting opinion, since it's coupled with advice.  I'll try looking at accessors with that in mind.  It would, at least, render this debate moot.  Or would it?  No, on second thought, I don't think it speaks about ''private'' accessors whatsoever.

ForgetAboutWritingAccessors:  This is the topic of another, different debate we've had.

ShouldMemberVariablesBeAccessibleToDerivedClasses:  It provides a good view of a neighboring area, but doesn't seem directly relevant.

UniformAccessPrinciple:  Appears to be pointed at language design, and the snippet doesn't include the rationale behind the proclamation, so I have no way of judging its quality.  On the other hand, I enjoy the fact that C# supports that principle.  On the gripping hand, I don't think it's germane to this topic.