[Tutor] designing POOP

[Alan Gauld]

"Kent Johnson" <kent37 at tds.net> wrote

>> The secondary reason is that a class author should be free
>> to change the internal data of a class provided he doesn't change
>> the message interface, but allowing direct access greatly increases
>> the risk that a change will break some users code. Particularly
>> if the change involves removing an attribute or converting it to a
>> derived value.
>
> That is the usual argument for getters and setters in Java and C++ 
> (at
> least). It makes sense for those languages but it doesn't hold water 
> in
> Python where a simple attribute can be changed to a property with
> whatever underlying functionality you like and no change in client 
> code.

While that's true, it does move the onus onto the class maintainer
to develop backwards compatible properties that may no longer
have any releavance to the internal method code. For example
a circle shape which moves from using a centre+radius system
to one which uses a bounding box, or vice versa. (Although it could
be argued that regardless of the implementation the radius/centre
should be properties of the circle)

But more dangerous is a database access class that stores the
tablename and then changes database schema such that two
names are needed, or vice versa, and direct access to that kind
of attribute would be a very bad smell indeed! Why does the client
need the tablename?!

I think we are in general agreement, albeit with different levels of
trust/toleration of the technique. Direct access is preferred to
getter/setter methods but is in turn less desirable that higher
level methods where they exist. The only contention seems to be
whether a values() type mutilple-return method is worth anything over
direct access. My personal taste is that if I need the entire 
"official"
state of an object I'd like a method to give it me in one piece, but
others obviously may feel differently.

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld