Generate Accessors

Simple question...

Why do the methods that are generated using the GenerateAccessors menu
item, generate them as private methods? I've always treated simple
getters and setters as more public than private.

Just curious,

Eric

Eric

You wrote in message news:[hidden email]...
> Simple question...
>
> Why do the methods that are generated using the GenerateAccessors menu
> item, generate them as private methods? I've always treated simple
> getters and setters as more public than private.
>...

>From Kent Beck's excellent "Smalltalk Best Practice Patterns":

'Getting Method' (p93)

"Here's the real secrect of writing good Getting Methods - *make them
private at first*. I cannot stress this enough."

(the last phrase is actually italicised and emboldened so I would say he
probably has stressed it enough :-))

'Setting Method' (p95)

"Everything I said once about Getting Methods, I'd like to say twice about
Setting Methods. Setting Methods should be even more private."

Fundamentally accessor methods break an object's encapsulation since they
reveal its internal state as part of its method signature. Ideally an object
should expose only "behaviour" as part of its public protocol. However in
practice the simplest approach may suggest public accessor methods. Kent's
words on this are better than mine: "There are cases where you will publish
the existence of Getting Methods for use in the outside world. You should
make a conscious descision to do this after considering all the
alternatives. It is preferable to give an object more responsibility, rather
than have it act like a data structure."

(This thread has the potential to start into a direct vs indirect variable
access debate, which would be really boring since it's been gone over so
many times before. In any case the Refactoring Browser makes arguments one
way or the other pretty moot, since it allows one to 'toggle' between them,
almost at will).

Regards

Blair

Blair McGlashan wrote:
Eric,

I really understand where you're coming from because prior to early
September I was not convinced that having plentiful getters and
setters was a bad thing.  I was introduced to Kent Beck's opinion
above and first thought it was Just Another Of Those Religious
Arguments.  But I've since come 'round to believing it is not,
indeed, his argument and recommended practice is essential.

At first I thought there was an equivalence between having getters
and setters marked "private" and not having them at all, the latter
being merely a stronger means of enforcing local reference if the
variables being so protected were instance variables.  I was heavily
influenced by Pat Winston's ON TO SMALLTALK in this regard.  But I
was convinced to think through this matter carefully, both because of
what Andy and Blair had said here, and what Ten Shen had said in
private correspondence to me in the context of a class we are taking.

Of greatest influence in convincing me on the matter was a couple of
readings of Nevin Pratt's "Separate Domain From Presentation"
(available) at

 
http://www.smalltalkchronicles.net/edition3-2/Pages/separatedomainfrompresentation.htm

Because of it I began to think about structuring classes in terms of
and
analogously to normalization of tables in relational databases.  That
isn't a connection Mr Pratt makes directly, but the idea of "Once
and Only Once" is what really motivates Fifth Normal Form and the
steps that lead up to it.  Why is that important?  It's important
because that's the only way one can assure that if a fact changes in
a huge corpus of information that you only need to update one record
of one table to implement the change.  It isn't (only) about elegance
or ideal design.  So, in class designs there is a conceptual set of
all possible ways of partitioning data and function and those ways
which allow for easiest extension and tightest coupling of similars
with similars have the fewest explicit or available links between
classes, whether the links are exercised or not.  The best design,
in the long run, is one which has a "lowest cross section" or
risk of potential impact from possible future changes.  Publishing
accessors to all instance variables allows other classes in a system
to "see" more into your implementation than they ought to, making
them dependent upon aspects of your implementation which may be
quite accidental and prone to change, and thereby hampering your
ability to change them at will.  Access of a method from the
outside is not, in Smalltalk, accompanied with a coloring of that
access as private or guarded in any way.  This is not, in my opinion,
a failing of Smalltalk but is, rather, a fact of how Smalltalk works
which needs to be properly considered when this marvelous tool is
used.

There are also other things. For instance, good Smalltalk coding
style puts a lot of emphasis upon intention revealing gestures
and design.  If one creates accessor methods it's natural for
someone reading the code to infer it is being published to the
world for a reason. If there is no reason, the gesture appears
frivolous.

I'm sorry to belabor this point, but I found it subtle.

[snip]

--
---------------------------------------------------------------------
 Jan Theodore Galkowski                    [hidden email]
 The Smalltalk Idiom                       [hidden email]
*********************************************************************
             "Smalltalk?  Yes, it's really that slick."
---------------------------------------------------------------------
Want to know more?  Check out
           http://www.dnsmith.com/SmallFAQ/
           http://www.object-arts.com/DolphinWhitePaper.htm
           http://st-www.cs.uiuc.edu/users/johnson/smalltalk/
*********************************************************************