[XML-SIG] foo.bar vs. foo.get_bar()

Thomas B. Passin tpassin@idsonline.com
Mon, 8 Nov 1999 08:49:55 -0500


To bring someone else's thoughts on this subject in, here are a few sections
from Martin Fowler's book, "Refactoring - Improving The Design Of Existing
Code", Addison Wesley, 1999.  This seems to be a most excellent book, by the
way.  The specific example language is Java, but it applies to object
oriented programming in general.

On page 206:

"One of the principal tenets of object orientation is encapsulation, or data
hiding.  This says that you should never make your data public.  When you
make your data public, other objects can change and access data values
without the owning object knowing about it.

... This is seen as a bad thing because it reduces modularity of the
program.  When the data and behavior that uses it are clustered together, it
is easier to change the code, because the changed code is in one place
rather than scattered all over the program."

This passage strongly supports using setting/getting functions, rather than
direct access to the attribute.  Read on for more:

On page 300:

"Providing a setting method implies that a field may be changed.  If you
don't want that field to change once the object is created, then don't
provide a setting method (and make the field final ) [this is a javaism -
TP].  That way, your intention is clear and you often remove the very
possibility that the field will change."

Fowler is very strong on having the construction of your code reflect its
intent as closely as possible, to aid maintenance and changes later on.

The problems people had using numpy, which were posted earlier in this
thread by David Ascher, when subclassing classes without getters/setters,
would seem to reflect what Fowler says here.

More support for spam.getParent()!

Regards,

Tom Passin