[Tutor] Design - getFoo and setFoo methods

[Andrei Kulakov]

On Sat, May 18, 2002 at 03:35:04PM -0400, Erik Price wrote:
> 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?
>
I don't understand this fully myself, but I guess if you have a
bunch of data, you can put it in a dictionary - a class instance
is an overkill, because it also allows you to have methods, which
you don't need.

person =
    {"phone":   "718 113 1134",
     "address": "1834 E13th St.",
     "name":    "Bartley McBartolomeu"
    }

instead of

person.phone = ...
person.address = ...

etc

Now if you had a function send_email to that person, it's better
to wrap it all in one object:

person.send_email(text)

instead of:

send_email(person_dict, text)

I think it's still okay to just use classes to store only data,
(if the overhead is not a problem), but it's not OO design, it's
just preferring obj.member syntax to dict[member]. IOW it's now a
matter of syntax, not design. Design is the same as in a
dictionary.

Again, I'm not too sure about all of this, so if anyone can
correct me, please do :-).


 - Andrei

-- 
Cymbaline: intelligent learning mp3 player - python, linux, console.
get it at: cy.silmarill.org