> "Getter and Setter
> > methods are evil" or something to that effect. Essentially
> it says that if
> > you have a method that simply returns any private data
> (such as properties
> > in a lingo object) that this is essentially just a cheat
> for making private
> > data public. Wow! Pretty strong statement. But it made me
> think. It goes on
> > to say that when one object requests another object's
> private data so that
> > it can perform a task with that data, there is a
> fundamental flaw with your
> > OOP structure (I'm paraphrasing here). Instead you should
> modify either the
> > object structure or move the task into the object that has
> the required
> > property.

<snip>

> That was exactly the point which got me thinking too. Some of
> the other
> stuff in that article (particularly to do with GUIs) is less
> relevant in a
> Director context because almost everything is part of the GUI
> anyway, but
> this is the suggestion that made the most impact on me:
>
> "Never ask an object for the information you need to do
> something; rather,
> ask the object that has the information to do the work for you."

<SNIP>

OK, so I've read Meyer's "Object Oriented Software Construction." I
write a lot of OOP code for all of my projects. tho I admit not all
because like others I need to "get things done sometimes." I would
definitly say I am into the OOP concepts. still, this absolutely no
Get/Set data statement is one of those purist things that is so
difficult to implement in real life, that I have a difficult time
adhering to it.

for example, imagine that you have an object to manage some MPG or QT
movies. you have an  object that monitors the state of the movie,
contains all the play/pause/stop type of functionality and keeps track
of the current position. you have a behavior that moves a slider
around that needs the current position data. would you

1) have the object publish the data publicly to a global variable?

this will work fine, tho I just try to keep globals down.

2) have an accessor method in the object so the slider can get the
data as needed?

this one goes against all the OOP principles that are expoused by the
big guys/gals, but it works well.

3) duplicate the movie location monitoring functionality in the slider
behavior?

this is OK but I hate duplication, and keeping this functionality in
the main object means that I only have to update it in one place.

4) include the slider functionality in the object?

IMHO this makes the object way too big & unwieldy.

5) something else?

is there something that I am missing, is there some other ground here?

hmmm...

Al Hospers
CamberSoft, Inc.
al<at>cambersoft<dot>com
http://www.cambersoft.com

A famous linguist once said:
"There is no language wherein a double
positive can form a negative."

YEAH, RIGHT





[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi  To post messages to the list,
email [EMAIL PROTECTED]  (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo.  Thanks!]

Reply via email to