Alan MacDougall wrote:
Dave Mennenoh wrote:
Lots of programmers never need design patterns as they don't help
much unless your architecting large apps, and lots of Flash
programmers aren't developing those kinds of apps. Keeping your code
organized however should be taught from day one and certain oop
concepts are perfect for that.
There are plenty of patterns that can apply well to small-scale
projects: take undo. How would you cleanly support undo without
Command? Other patterns like State, Adapter, Observer (especially to
overcome the sadistic limitations of Flash's single callbacks --
MovieClip -- or single listeners -- MovieClipLoader)... all have uses
even in a sporty little website tchotchke. Not every 'design pattern'
is something like MVC or data mapping or dynamically-configured
factories.
On the other hand, I got your point.
Design patterns are not some esoteric way of doing things. They are
solutions to common programming situations that came up over and over again.
For years, we all wrote our own way to accomplish these tasks. Finally
some experienced guys looked at what they were doing and what other
people were doing. They had a "Holy Sh*t" moment when they realized that
they had 50 ways to do exactly the same thing. They looked at the
various ways and tried to pick the best strategy.
A design pattern book is not a road map to building an application. It
is a collection of best practices for the tasks that come up all the time.
It hard to imagine even a small program that could not use at least one
of the design patterns that have been identified.
It is hard to imagine a Flash program that would not be a candidate for
several design patterns. A game with no Listener/Observer is hard to
imagine. (How many onEnterFrames does it take to kill a program? )
How do you handle onLoad's famous scope? There is a design pattern for
this and it gets explained every time a new flashcoder tries to read an
XML file. You can probably find this in the archives once every 2 weeks.
They do not call it a Design Pattern but it is.
If you doubt the usefulness of Design Patterns, read Head First Design
Patterns. You will read each section and sometimes be amazed at the
simplicity of the solution and wonder why you never figured this out. In
other sections you will say "What is the big deal? I do it like this all
the time."
It is not magic or advanced. If a pattern was shown to a new programmer
without giving it a fancy name, they would just accept it as the best
way to do the task and would never give it moment's thought. If you were
trying to get the class to build a game, you would be foolish not to
explain the Observer pattern. It is very simple and the alternatives are
often really ugly and overly complex and frustrate the best of us.
Ron
_______________________________________________
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
_______________________________________________
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
