Jakob Hede Madsen <[EMAIL PROTECTED]> wrote
> > > 3.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.
>
> Bullocks. This guy must be living in a dreamworld.
> If I have a baddie hunting the goodie, then the baddie asks the
> goodie about its data such as position and direction, and then the
> baddie himselfs takes appropriate action. It's not like the baddie
> then asks the goodie to help the baddie catch him.
As is typical in all borderline OO examples, you've taken this from the
game design world. The other classic for breaking (or testing) OO purity
is collision detection.
Jakob, I know your OO credentials are impeccable, but I find it
interesting that some of the most stubborn anti-OO vectors come from the
game design community (both within and without the Director world.) This
implies that OO is essentially detrimental to performance, which is
another issue altogether, and one that has been proved to be both true
and false on several occasions.
I would argue that the baddie asking the goodie about its position and
direction is tantamount to asking the goodie to help the baddie catch
him, especially if the baddie has no other purpose but to catch the goodie.
Asking the quarry for its position might seem like the worst form of
cheating for some hardened hunters and trackers, but as a shortcut for
making a computer game, it works ok, and (most important) it's fast.
It's *not* clean OO though.
Let's go into the problem domain, not the Comp.Sci domain;
Real hunting is about traces in the environment that the hunter is
highly attuned to, so if we were going to do it properly, the 'goodie'
should probably tell the environment object where it is (or even deposit
a packet of digital 'pheremone' which degrades and/or dissipates over
time). In fact, this should be a side effect of the goodie's movement
in/through the spatial element(s) of the environment.
The environment would contain both the goodie and the baddie as its
elements, so the baddie would be informed by the environment of where to
hunt, not by the goodie directly.
It's more bureaucratic this way, but if we are talking about OO purity
and clean implementations, it's pretty tight. I don't see any need for
getters or setters with this model. All data remains private. Internal
data is only exported from objects actively as parameters of handler
calls, so each object is in full control of what data is shared with the
outside world.
In practice, I'd almost certainly do it exactly the way you suggest for
performance reasons, which is why I'm only prepared to fly the OOP flag
*some* of the time. :D
OTOH if I was programming simJungle or something, where elaborate food
webs of predators and prey could be established and maintained, I'd
probably do it the clean way.
> > >5.All objects must provide their own UI.
>
> I don't understand.
Yes, this was the bit I found most problematic too, at least as far as
translating to lingo goes. Java (of course) has a rich set of standard
classes for GUI, including powerful layout managers, but it is not
necessary to invoke them at every level, so this suggestion is more
meaningful in that context. In Director, almost everything you do is
contained within UI (you can't have a command-line-only Director
application), so it's kind of moot.
The other thing is that he is overlooking the idea of granularity. If we
were hardened Smalltalk programmers, working in Java and feeling dirty,
we'd probably want to avail ourselves of Java's data primitive classes,
so that we could send add() and subtract() messages to our integer and
float objects. Clearly, these objects don't provide their own UI because
they are too low level.
Anyway, I stand by the suggestion that 'getters' and 'setters' are
impure OO. That's not to say I wouldn't use them.
--
_____________
Brennan Young
Artist, Composer and Multimedia programmer
mailto:[EMAIL PROTECTED]
"Well I started on the piano, then I moved onto the coffee table."
-Stephen Fry
[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!]
