>Most of all, it strikes me that if an object needs to see another
>object's property, then something is wrong with the encapsulation.
>Surely, objects provide *services*, not access to their guts.
Brennan, to my mind, you've gone to the heart of the matter in that statement.
I try to write my OOP code in a way that you can ask an object for
information about itself. How it cares to return that information is the
object's business.
Need to know another object's position? Have a myPos handler that returns
the x, y, and maybe z coordinates. You don't need to know what the object
is calling them.
Need to know its size? Same thing. Position? Speed? Which sprites it's
attached to? I can't think of anything you need to know about an object
that can't be reported by the object, without anybody else knowing the
properties' names.
You may have to write a new method in the old object to report the
information you need (or ask another programmer on your team if it's their
code).
This really goes to the heart of encapsulation. The whole idea is that the
object is a black box. You don't need to know a thing about the object
except for its public methods. That way you can rewrite the entire object
if you want, as long as the public methods still return the values you ask
for, or do the processing you ask it to.
Having said that, I'll acknowledge that there are times when it's expedient
to expose an object's data. For example, I recently wrote a program that
had one sprite bouncing around the screen, and 44 other sprites reacting to
it. For performance, I used globals for the floater's position and
direction, because it was faster for the other objects to access a global
than to do a sendAllSprites from the floater.
Cordially,
Kerry Thompson
Learning Network
[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!]
