> I've been following this thread with a certain amount of puzzlement, but
> here you completely lost me...
Sorry 'bout that. I've been really under the gun this week so my
explanations have not been as full bodied as I would like them to be.
> The way I see it, the moment you define an accessor method in your object,
> you automatically declare the property it accesses as public.
> That's the big
> difference. You don't just grab any old property from an object, as you
> would with direct access, instead you politely ask for a property that the
> object "decided" that it's willing to give.
> Also, you don't just get the property: By using a "getter" method
> you allow
> the object to decide what information it wants to give you. It can either
> give you the value of it's property "as-is",
And that's my point. A property variable by it's nature should be local to
an object. Whether it's polite or not you are allowing one object to divulge
"Private" data to another object. This means that you have broken out of the
black box and your object may no longer be as modular as it could. Brennan
makes a point of this with the QT/Slider example which I have quoted later
in this email.
> or make some pre-calculations
> and return a value that isn't even stored as part of it's properties.
Now your talkin'! This is what I mean. You need to ask yourself why do I
need this property from this object. Can I instead "make some
pre-calculations" within the object and return that result back to the
requesting object.
> I suppose the main requirement of the
> accessor methods is to supply/set the data required in such a way that
> the object can be perceived as a "black box". ie you should be able to
> change the implementation of the method without affecting any other
> objects that make calls to the method. As long as the method continues
> to take the same arguments, and return the same results we have achieved
> this...
But it is no longer a "black box" if you are returning private data. Again
reusability becomes an issue.
> >Some people argue that this is perfectly acceptable because you have not
> >tried to access the private data directly (i.e.:
> objectA.pPrivateData) but
> >instead used a getter method to access it. But what's the difference?
>
> The difference is that one is public and the other is private, and
> the difference is that using a method rather than prodding directly
> into the objects property, respects its implementation hiding.
But does it, and again is it reusable? Here's an example. I'm gonna do a
twist on the ATM example seeing as there is one in the article.
I see you in line at an ATM. I remember that you owe me money (No, really
you do). So how do I go about getting it from you. Do I wander over and
"request" your PIN number so that I can punch it in and pull the money out
myself (obviously you would oblige me your bank card). No I do not. Your PIN
number is private data and though this is a valid way for me to get my money
back, it is not a method I use... Not simply because I am accessing private
data but because my method is not at all reusable. Instead I simply
"request" my money and you do the task of extracting it from the ATM for me.
Now I notice your friend is hanging around the corner from the ATM. I
remember that he owes me money as well. I again do not request his PIN
number but rather make a request for the money. And a good thing that I do
because unbeknownst to me he does not even have a bank card. Instead he
gives me the cash directly from his pocket. Now I have a method that works,
and it works under a variety of conditions. It is reusable where as a method
that requests private data from an object may not be.
It's now to the point that when I find myself requesting any property of an
object (whether I do it politely through a method call, or not) I pause and
contemplate if there is a better way to implement this task. To be honest
sometimes I don't always find a way. This may have to do more with tight
deadlines than lack of a way.
> Perhaps a better idea is that of using messages. Rather than exposing a
> slider's position in a method, have it send a message to the video object,
> "update your frame based on this data, here it is." This leaves
> it up to the
> video object to decide what to do with the data and the message, and the
> slider can generate the data any way it pleases.
In the case of the QT/Slider example I think this works very well.
> In the Quicktime wrapper example, I see no reason why the slider should
> 'know' about the Quicktime movie, and I see no reason for the QT
> wrapper to
> know how 'progress' is expressed by the object it calls back, which might
> just as well be a field displaying an integer.
>
> If the slider is asking the Quicktime sprite for movietime, or calling the
> Quicktime wrapper's getMovietime() function, then the slider is
> not general
> enough to be used for other things than Quicktime controller sliders.
Brennan has hit the nail on the head.
> so a slider function should only be passing the current slider knob
> location as a % of the slide. thus it could be used for anything that
> would use a slider, not just QT! OK, that's good.
>
> 1 - so how would a slider behavior know what object to talk to? would
> you enter the global reference to the QTObject in the
> getObjectProperties dialog?
I must of missed a previous post what do you mean by getObjectProperties.
Otherwise use whatever method you are comfortable when creating objects.
Whether that is using a global variable for each object or a single propList
that contains all your objects. Some people use a property variable in
sprite 1 as an object manager, to avoid using global variables. I believe
one could even use a Movie Variables in this case, to track all your objects
(never tried that, but there is an article on DOUG talking about Movie
Variables, could be interesting to use as an object manager).
>
> 2 - what would you suggest for a method name for this function in the
> QTObject?
qtObj.soJustHowFarAlongAreYou()
Seriously this is one of the more difficult things I find in attempting to
make objects reusable under a wide range of conditions. We want the slider
object to work just as well with say a bitmap as it would with a QuickTime
and the name should be intuitive enough for both. We have already
established that the method should return a percent position so how about:
relativePosition()
or
returnRelPos()
It's weak I know... any one else got a better name?
ck
[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!]
