[Tutor] Accessing class attributes: use methods only?

[Alan Gauld]

"Chris Lasher" <chris.lasher at gmail.com> wrote

> Now for more discussion: I'm confused.

:-)
Actually there is no real contradiction. I'll try to explain
and if I misrepresent Kent I'm sure he'll say so!

> Kent Johnson's statement:

>> Python practice is to use direct attribute access. If you need to 
>> do
>
> So to paraphrase, he states it's the Python way to do:
> my_instance = MyClass()
> my_instance.x = 42

And this is quite correct. In fact I specifically said in my reply
that if you really *must* access an attribute of a class it is
better to just do it directly than to write setX/getX methods

> On the other hand, we have Mr. Alan Gauld, who states:
>> Its generally good OOP practice to interact with object via 
>> messages.
>> Its also good practice NOT to access an objects attributes directly

So what I'm saying is that you should try to write classes
such that nobody ever needs to access the internal data. If a
user needs access to the internals it is often a sign that there
is some functionality of the class missing. Why do you need
the data? Shouldn't the class that owns the data do all the
manipulation of it? That's what OOP is supposed to be
about - creating objects which receive messages that tell
them what to do. Some of those methods will return data
values but you should neither know nor care whether they
are data attributes internally or whether they are calculated
values.

> So to paraphrase, he states it's the right way, regardless
> of language, to do:
> my_instance = MyClass()
> my_instance.setx(42)

No, I'm saying it's the wrong way regardless of language to do that.
(With the exception of JavaBeans - and not all Java classes need
to be beans! - because they rely on the set/get protocol to
support IDEs etc)

More usefully you should hopefully have a method that has a
meaningful, operation-based name, that results in the internal
variable x being set to 42. But that should be a by-product.
The user of the class should not, in general, even know that
x exists!

Now that's in an ideal world and as such it doesn't exist. So we
don't always have that luxury. And some objects are more or less
just data stores - but they should be the exception not the rule!
In those exceptional cases, if you need to access a data attribute,
then it's OK to use direct access in Python.

> I'm used to just setting and getting attributes straight, which 
> would
> be Pythonic according to Kent and yet also outright wrong according 
> to
> Alan and academic papers. So is direct access actually not Pythonic,

Direct access is Pythonic *when necessary*.
Direct access 9including via set/get) is wrong in an OOP sense in
any language. The methods should expose a set of operations which
do everything you need to do without your knowing about the
internals of the object.

> Pythonistas spit in the face of Demeter and her lovely laws?

Nope, but Python allows you to break the laws in the simplest
and most direct manner. One of Python's tenets is that we are
all responsible programmers. When we break the laws of good
programming we do so in a deliberate way, fully aware of why
we do it and of the potential consequences.

So both Kent and I are saying the same thing: don't use
setX/getX; use direct access if you have to. But I add the caveat
that you should try to avoid the need for direct access in the first
place.

HTH,

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