Posted by Chris Uppal-3 on Jan 18, 2005; 12:38pm
URL: https://forum.world.st/The-cost-of-sending-a-message-tp3372722p3372754.html

Fernando,

> > [...] and anyway the very concept of "accessor method" is
> > an affront to OO thinking.
> [...]
> I agree that using an accessor method from within the the class
> doens't make any sense, but you seem to go further and consider the
> usage of any accessor method fundamentally wrong. Is this correct?

First off, let me emphasise that this is all only my personal opinion.

What I meant was that the /concept/ of an "accessor method" is non-OO.  I have
no objection whatever to a method that answers an object's height, even if it
is coded as:

    height
        ^ height.

(except that I would deplore the absence of a comment -- "height" is by no
means an unambiguous word).  On the other had the method might just as well be
coded:

    height
        ^ self map: altitudeAtMapReference: self mapReference.


or:

    height
        ^ intialHeight + (growthRate * age / 100.0).

or:

    height
        ^ top - bottom.

(possibly with a few more self-sends scattered around if you like using private
accessors)

What I do object to is the notion of a method whose /purpose/ is to read (or
write) the value of one of the object's instance variables.  /That/ is a
violation of encapsulation.   The caller should not care at all about how the
receiver represents its state, but only care about its documented behaviour.
If the method #height is part of the defined behaviour of the object, but just
happens to be implemented as a simple read of an instance variable, then that
is Fine By Me.  But in that case the method is only "accidentally" a getter
method, it has the /form/ of a getter method, but that's not how it is intended
to be thought of.

In my experience so far, most people who talk about getter/setter methods, or
accessor methods, /are/ thinking in terms of methods that change the values of
objects' instance variables.  And to me, that is a failure of OO thinking.

A few caveats:

One is that /private/ accessors aren't (IMO) a failure of OO.  I don't like
them myself (as a matter of readability and convenience) but I don't think that
they are actually /evil/.

Another is that sometimes you do need methods whose deliberate purpose is to
read/write an instance variable (and which would change if/when the IV
changed).  This may be necessary in reflective contexts if #instvarAt: (and its
friends) is not appropriate.  Such contexts are rare.

A last is that some people may have/use a different concept of what an
"accessor method" is.  They may mean something more general (or abstract),
like:
    They are quick, callers can assume that they run in fast
near-constant-time.
    They come (usually) in pairs of a "getter" and "setter".
    The "getter-style" member of the pair has no visible side-effects.
    The "setter-style" member of the pair is idempotent.
    The "getter" will always return the value set by the last "setter" unless
something else changes.
    etc...
If that's how someone is thinking about the "accessor methods" then I wouldn't
complain so much[*] about OO.  I would suggest, though, that that's not how
most programmers use the term[**].

One last point is that some of the advice to use "accessor methods" comes from
Java/C++ programmers, and what they mean is "use accessor methods instead of
publicly accessible instance variables" (there's no such option in Smalltalk,
of course).  I agree that they are better than public instvars, but that still
doesn't make them /good/.

HTH.  Please don't read too much into it; it is, as I said, just my personal --
and rather extreme -- opinion.

    -- chris

(
[*] I might still complain a bit -- lots of simple methods that merely get/set
some aspect of an object's state may indicate that the programmer is expecting
work to be done in the caller that the object should be able to do itself.

[**] Although I admit that I put lots of methods into the Dolphin method
category 'accessing' -- and that's how I'm thinking of the word when I do it.
)