I'm wondering if AS2 offers any advantages to me, or if sticking with AS1
would be better. Is AS2 (and now 3) the natural progression of Flash
coding,
is there even a future for AS1, all the useful libraries seem to be AS2
only
these days too, perhaps that alone is a reason to switch. I'm unsure as to
what path I'm supposed to be on.
Any advice you could give me would be appreciated,
Ok, here's my 'designer who codes' or 'coder who designs' ("jack of all
trades, master of none") point of view:
AS2 is the right way to go. However, knowing when to apply each different
approach (doing everything on classes, doing everything inside the flash
movie, and all between) is the real issue.
If I want to create something quick, I usually create a movieclip with the
functionality I desire. It kind of mimics a class, or a component, but it's
neither; it's just a movieclip where I can quickly change something on the
code or on the graphics. Like a "smartclip" (heh). It's on this case that
some of the best OOP features (such as design patterns) also comes to help.
I treat like movieclip as a 'black box' (like a class..) so they do some
minimum talk to each other, trying to be standalone on what they do.
However, under AS2, the 'right' alternative would be create a new class and
attach it to the movieclip. But I've grown tired of that approach, since I
have to keep creating a lot of classes just to modify the functionality of,
say, one menu. And I'm not building apps; I'm building 'designer' websites
(see samples at zeh.com.br). This doesn't mean I build them like crap, or
that they have 'loosy' requirements when compared to an app; but it means I
build them quickly (taking around one month) and intelligently (or at least
I like to believe), not over-designing and making sure everything's on a
class and properly commented with javadocs and with UML diagrams and
whatnot. It also means I almost never reuse code between websites; each new
menu is a new menu, because it works in a much different way than the
previous menu I built. That's why I can't just create generic classes for
everything and extend from there; I'd have way too many classes.
I do, however, use classes for all kinds of semi-generic functionality I
need; reading XMLs, tweening, localization, trigonometry - it's all done on
classes. When it comes down to real-life work, obviously there's no point in
reinventing the wheel, so I try to build these generic tools that then I can
apply on my work. But that's the limit. The rest is too specific to be
reused.
I know this approach will be not be seen lightly on the eyes of more purist
coders. However, I like to believe my line of work requires a different set
of development skills - yes, I do try to make my code and design as
maintainable as possible and as easy to understand as possible (ie, full of
comments, not using spaghetti code, etc), but breaking eveything into tiny
classes just won't work, it'll be too much effort for too little advantages.
Like I said, I believe finding the correct balance between the two
approaches is the best answer - and there's no easy way to do it, it depends
a lot on the kind of work you're trying to do, how long do you want it to
live, how maintainable you want it to be, etc.
IMO.
- Zeh
_______________________________________________
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
