Load Accessor

A LoadAccessor answers the value of a DefinedAttribute.

I like to use LoadAccessor(s) and StoreAccessor(s) to provide (usually private) access to a DefinedAttribute. I use them in conjunction with patterns for initializing attributes, persistence, naming, and so on.

-- TomStambaugh

On ChryslerComprehensiveCompensation we do not use accessors unless someone external to the class needs access. We have been doing this now for over two years and it has never given us the least problem.

KentBeck says he is schizophrenic on this subject. I think he meant multiple personality disorder. Whatever it is, I am also. I have cycled back and forth on this a number of times, and am now firmly stuck on not using accessors.

All the arguments for using accessors on a class with no external requirement for them are arguments about the future. ExtremeProgramming people never do things for the future. YouArentGonnaNeedIt. This always saves time now (and after all, we are here now) and seems to always save time in the long run. Plus, the code is easier to read. --RonJeffries

That sounds like a problem with shield weight (terminology from ShieldPattern). In a language which mapped all variable accesses onto getter/setter functions transparently, there would be no extra cost and you could not avoid using this pattern. (I think SatherLanguage is such a language. Also CecilLanguage and probably DylanLanguage. EiffelLanguage does about 1/4 of the job.) I like this pattern, which is to say I think those languages are right to enforce it transparently. -- DaveHarris

RubyLanguage also has this transparent mapping of variables/getters/setters.

JavaScript and DylanLanguage back attributes with invisible but redefinable getter and setter functions.

Many IDE's provide this for Smalltalk and Java, as well. The important thing, for me, is to be able to make my own patterns for the resulting code. I reject the Java convention of prepending "get" and "set", for example, and I use patterns that let me easily move back and forth between EagerlyInitialized and LazilyInitialized attributes. -- TomStambaugh