#include vs import

Question

I'm trying move towards a more oop approach in my coding but
often wonder how far to go. My sites are entirely in Flash and load
all the initial .swfs in sequence behind a progress bar until the
home page can go active, after that the loading sequence continues
behind the scenes until the whole site is loaded. I've cleaned up
the code for this loading sequence into a set of functions with a
single initiating call and put it in an .as file which I #include.
Having gone that far it would be fairly simple to convert this to a
class but apart from being "the right thing to do", would there be
any advantage? The code runs only once and I easily re-use it on
multiple sites by storing the .as file in a common folder.

Answer 1

Bob,
> Having gone that far it would be fairly simple to
convert
> this to a class but apart from being "the right thing to
do",
> would there be any advantage?
This isn't always true in real life, but in programming,
"the right
thing to do" is a flexible concept. In programming, "the
right thing to do"
is generally whatever works best for your workflow, or the
workflow of your
team. If you don't see the benefit of a certain recommended
best practice,
why go to the trouble?
For example, I like Turkish coffee. The way I prepare it,
the process
takes quite a while. I have to grind my beans into,
essentially, flour. I
add the "flour" to a special conical pot, along with sugar,
cardamom, and
anise, and heat it -- but not to boiling -- until it starts
foaming. That
takes about 20 minutes. It's extra work, but I absolutely
love the stuff.
Totally worth it. And it helps my workflow. ;)
In Flash, when coding on the timeline, I put (most) of my
code in a
layer dedicated to solely to ActionScript. Why? Because I
personally find
it easier to locate my code when it's all in one place. Most
of the
developers I know find this practice equally helpful, so it's
no surprise
that it's a recommended best practice.
I personally prefer the dot notation approach to event
handling in AS2.
To me, the older approach -- on() and onClipEvent() -- is
less powerful and
flexible. (See the link for details.)
http://www.quip.net/blog/2006/flash/museum-pieces-on-and-onclipevent
As it turns out, avoding on() and onClipEvent() is nowadays
considered a
recommended best practice. It's the "right thing to do" ...
but plenty of
folks still use on() and onClipEvent(). At least, they do in
AS2 (it's not
possible in AS3). There are rare occasions when I still use
the old
approach -- for a quick banner ad, say -- and I do so when
that's the most
convenient route.
In your case, there may not be an immediate advantage to
converting your
#include code into a bona fide class. (Of course, there might
be after all!
Only you can determine the answer.) The general reason for
writing
something as a class is to make it portable; that is,
conveniently reusable.
I'm in the middle of a tutorial series at CommunityMX.com
right now that
describes a class for wiggling the characters in a string of
text. I'm sure
you've seen plenty of nifty text animations in Flash ... the
ones where,
say, characters fly in from the side and flip into place.
This sort of
animation requires individual text fields for each character,
so that each
character (each text field) can be animated individually.
http://www.communitymx.com/abstract.cfm?cid=ECBF0
To make this potentially tedious effort reusable, the
routine that
creates all those text fields can be wrapped up in a
function, then called
from any frame after the function's definition (including the
frame in which
it appears). To make things even easier, the function (and
any related
functions) can be wrapped up in a class. This reduces the
amount of code
that appears in the timeline -- which is also true of your
#include code --
and, in the case of the wiggling text, can be as easy to use
as this:
var wt:WiggleText = new WiggleText("Here's the string");
wt.x = 200; // position the wiggle text
wt.y = 300;
The WiggleText class works just like the Date class, or the
Array class,
or any other convenient "building block" in the ActionScript
arsenal.
Writing a class gives you an actual *object* that can be
manipulated like
any of the native objects in Flash. If the concepts behind
your #include
code can be distilled into a reusable object -- something
flexible and
configurable -- then it will probably help your workflow, in
which case
writing it as a class is the right thing to do. If not (but
if you're
interested in writing classes), then you can leave it as
#include for the
time being and experiment with the concept in another venue.
Until it
becomes fluent. When class writing makes sense on a gut level
to you,
you'll know when the practice is worth it in a given usage
scenario.
A chess coach often suggested that I not make a move ...
until I had
thought through all the reasons why moving that particular
piece was a good
idea. Sure, I could study opening moves ... I could memorize
which moves
were among the group of "right things to do," but until I
understood why --
and agreed that reason was right for my game -- ... well, you
get the idea.
David Stiller
Co-author, Foundation Flash CS3 for Designers
http://tinyurl.com/2k29mj
"Luck is the residue of good design."