[Tutor] Design - getFoo and setFoo methods

Erik Price erikprice@mac.com
Sat, 18 May 2002 15:35:04 -0400


Whoah Alan can we back up just a minute here... new to OO design myself 
so I am curious about this subject.  First some context:

> getXXX/setXXX makes sense if the XXX is a property accessed
> via a common protocol(like in JavaBeans) by a Tool (like a
> GUI builder).
>
> They also make sense if you put valuidation code in the
> set method to check the values lie within constraints.
> Or put security checks to make sure the user has valid
> access rights.
>
> But as a general principle they are a bad idea since they
> basically break the principle of data hiding. You should
> access objects using a behaviourally focussed API and
> the internal function of the methods should determine
> the data held. The data(attributes) should only be there
> to support the methods. Of course the methods may be
> there to expose data but usually this will be ion a lump
> not single attributes(eh a getAddress() method retuirns
> several fields not just one and a getAddressString returns
> the sae info as a single string. How it is stored internally
> is unknown and irrelevant to the class user.

I think I understand what you're saying.  But it goes against what I was 
originally thinking when I was learning about objects.  According to the 
above (I think) an object is there to perform certain actions or 
behaviors.  This may include the handling/storage of data, but not 
necessarily.

I thought that the idea of object oriented programming was to treat 
everything as objects, which helps organize your code.  What you're 
saying above is that objects don't exist to turn data into objects but 
rather code constructs into objects.  What's the official word?

Here's another, related question -- I use objects to store bunches of 
data in my application, for instance a Person object keeps track of a 
name and a database primary key ID number, etc.  A subclass of Person 
could be Recipient, who is someone with an address and a preferred 
shipping method.  However, I've been taking a shortcut in my code 
(because I didn't know any better) by directly accessing the attributes 
of the class in the code itself.  But in a book I am reading (Beginning 
Java Objects by Jacquie Barker) it is recommended to use setThing and 
getThing methods instead.

Why do I do this?  Well, because in one part of the application I need 
to display a Recipient's address.  I would normally do this by creating 
a method in the Recipient class definition to display an address.  But 
in another part of the application, I would do the same thing but the 
Recipient's name needs to be a hyperlink that points to a certain page.  
So that means I have to create a whole new method that does the exact 
same thing as the previous method but turns the name into a hyperlink.  
Not only does this seem clumsy, but URL in the "href" part of the 
hyperlink may change depending on circumstances.

So right now, I just pull out the class attributes and the calling code 
does the work.  But this seems to be NOT object oriented at all.  One 
way around this would be to make a class to display addresses, and then 
a subclass of that which displays addresses with names as hyperlinks.  
But these things seem less like objects and more like methods, so I'm 
kind of hesitant to do that.  And as far as defining the content of the 
"href" attribute, I could probably pass this as a string argument to the 
method...

it gets very confusing.  What would a Real Programmer do in this 
situation?



Erik