[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