[Tutor] Design - getFoo and setFoo methods

Alexandre Ratti alex@gabuzomeu.net
Sun, 19 May 2002 11:18:27 +0200


Hello,


At 21:06 18/05/2002 -0400, you wrote:
>Date: Sat, 18 May 2002 15:35:04 -0400
>Subject: Re: [Tutor] Design - getFoo and setFoo methods
>From: Erik Price <erikprice@mac.com>

[about getFoo() and setFoo() methods:]

> > 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?

My understanding is that objects are chunks of (actions + data). Their 
behaviour will be "doing something to/with some stuff" (not a very precise 
definition, I'm afraid).

>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.

<suggestion type="stab-in-the-dark">
I have a related situation: in one app, I have "macros" (actions carried 
out on data). The macro results need to be rendered to HTML. I use two 
objects: a FooMacro class and an FooMacroRenderer class. I tried to 
standardize xMacro classes and xMacroRenderer classes along different lines 
(the ones select/transform data, the others display it in HTML format).

Maybe you can try to look at your problem in this way. Maybe the 
"displaying" part of the problem does not belong in the Recipient class.


Cheers.

Alexandre