At 4:03 PM -0400 8/20/01, Al Hospers wrote:
>Irv,
>
><snip>
>
>yes. in my last post I said that both should be behaviors in this
>example. at first I was trying to talk about this as an object just
>for the sake of argument. then I realized that this was getting
>confusing & so I just stripped it down to the final question which I
>still haven't heard answered:
>
>"if you can't use accessors as the article implies, how do objects or
>behaviors communicate?"
The basic idea of an accessor is that it is a specialized method
which just gets or sets a property variable within an object, like
this:
property pSomeProperty
...
on mGetpSomeProperty
return mSomeProperty
end
on mSetpSomeProperty me, someValue
pSomeProperty = someValue
end
The author of the article was basically saying that methods like
these above should never be written (he would have a coronary at the
sight of a Lingo statement that went directly into an object and got
a value: SomeObject.pSomeProperty = 5 (don't do that!!!)) His
point is instead of allowing some other object to get or set a value,
you should always any code that manipulates a property in the object
that defines that property.
In my online book at http://www.furrypants.com/loope I write about
two views of an object - "inside" the object and "outside" the
object. The author of this article was talking about what I refer to
as "outside" the object. That is, how do you view and communicate
with the object from outside of the object - what are the methods you
can call in the object. This is what he was referring to as
"capabilities". Certainly, objects can be written to do useful work
without any accessor methods. From the outside, it doesn't matter how
the object does what it does. That's the essence of "encapsulation".
But then, we are programmers. When we build an object, we must also
think "inside" the object. What are the property variables that the
object maintains? How do the different methods inside the object
work together to share, use, and affect the property variables?
In my book (so far) I discuss a Sound Manager. The Sound Manager has
a set of capabilities. You can call its methods to start an external
sound, start an internal sound, etc. Each action is a method call.
You pass in any required parameters. The Sound Manager does what it
needs to do, and from the outside, you don't care how it does what it
does. There are no accessor methods, yet the Sound Manager performs
some very useful functions.
Does that help?
Irv
--
Lingo / Director / Shockwave development for all occasions.
(Home-made Lingo cooked up fresh every day just for you.)
[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!]
