Object Oriented Programming
|
Like everything else in our lesson kit, Object Oriented Programming (Oop) is easy. Naturally, the purists will
decry our simple-minded imprecision, but so it goes. Some folks insist on rigid confusion while others thrive
on patterns of similarity and pictorial notions characteristic of the natural human thought process.
In this regard, the similarity between Lingo "Behaviors" and Oop "Parent Scripts" cannot be ignored.
|
Speaking imprecisely, when you drag a Behavior onto a sprite, you create an implicit child object
(of the Behavior) that is automatically associated with the sprite. Meanwhile, with Oop, the dragging
of Behaviors is replaced by a bit of code. In other words, if you understand Behavior dragging, then you
can understand the basics of Oop. It really is that easy.
|
Side-by-side Comparison(a simple example)
|
|
Lingo Behavior
|
 |
Lingo Parent Script
(named "RightShover")
|
|
Property mySprite, A, B
On BeginSprite me
mySprite = Sprite(me.SpriteNum)
A = mySprite.loch
B = 0.25
end
On Exitframe me
A = A + B
mySprite.loch = A
end
|
|
Property mySprite, A, B
On New me, passedSpriteNum
mySprite = Sprite(passedSpriteNum)
A = mySprite.loch
B = 0.25
return me
end
On Stepframe me
A = A + B
mySprite.loch = A
end
|
In the example above, the similarities are obvious:
- The Behavior and Parent Script have identical Property variables.
- One has an "On Beginsprite" handler while the other has an "On New me", each of which initializes
the Property variables.
- One has an "On Exitframe" handler while the other has an "On Stepframe" handler that serves the
same purpose (moves the sprite slowly to the right).
|
Differences are several:
- The Behavior is automatically associated with a Sprite while the Parent script
is not. In fact, a Behavior MUST BE associated with a Sprite, while the Parent script can run without
any Sprite at all.
- The Parent script returns "me" while the Behavior does not.
In addition, the two scripts are implemented within your Director program somewhat differently.
The Behavior is simply dragged onto a sprite, while the Parent Script must be called explicitly
from elsewhere in your code as shown below.
|
Implementation In Your Code
|
Lingo Behavior
(Creates "implicit" Child object.)
|
 |
Lingo Parent Script
(Creates Child of Parent script.)
|
|
Drag the behavior onto a sprite.
|
|
On Startmovie
dum = new(script "RightShover", 5)
add the actorList, dum
end
|
|
The above example assumes that the Parent Script is named "RightShover". It also assumes
that sprite 5 is to be associated with the Child object.
'new(script "RightShover", 5)'
runs the "On New..." handler of "RightShover",
which returns a reference to the new Child object.
The returned reference is then added to the actorlist, and this completes the implementation.
The actorlist is a "special" list that contains Child object references explicitly added to the list.
Every Child in the list receives a "Stepframe" message whenever the playback head enters a frame OR
the Stage is updated.
|
The similarities continue when sending instructions to the Behavior or to the Child object. For example,
if a Behavior includes the handler "HopUp", then you can use the Lingo "SendSprite" command to invoke
the handler. If the Child object also has a "HopUp" handler, then you can invoke it via the command
"adum.HopUp" (this assumes that "adum" is a reference to the Child object).
In summary, this illustration shows that you can use Oop to mimic the effects of Behavior dragging.
HOWEVER, this is only one example, and as you'll see below, Oop is far more elegant and powerful
in complicated multi-Sprite interactions (for example).
|
|
Oop Advantage
Overall, when dealing with individual Sprites that operate in relative isolation, it is usually
slightly easier to drag behaviors than to mess with Child objects and Oop. However, when dealing with
groups of sprites, Oop gains a significant advantage because each Child object is NOT associated with
one specific sprite. Instead, each Child object can reference many Sprites and deal with them as a
unified whole.
For example, suppose you have N Sprites and you want to write a single Behavior that causes them to
collide smoothly in one second. Somehow, the N instances on the Behavior must communicate to coordinate
their motion and collision. This might use Global variables, or maybe creative use of the SendSprite
command.
|
In contrast, Oop can handle the entire animation within a single Child object. So long as the object knows
which Sprites to control, it can coordinate all of their movements and eventual collision. No
intercommunication between Behavior instances is required. Instead, the object simply "does its thing"
and the collision occurs.
In other words, Oop might be viewed as the compartmentalization of complex interactions
— similar to a "Plug 'n Play" graphics card that can be installed without soldering a bunch of
extra wires to your motherboard and power supply. Yes, you COULD bandaid the card in place with a
bunch of wire and tape; but it's much easier to install it as a seamlessly compartmentalized product.
Similarly, any Oop can be replaced by a bunch of Behaviors, global variables, and Movie Scripts.
However, the ensuing mess can rarely be justified.
|
Back to Lessons
|
