I’m a firm believer in stability.
Build it, test it thoroughly, and move on to the next piece of the puzzle. If the pieces are stable, they’ll work in harmony together, and you can build more powerful applications.
Which is where design patterns, and particular, MVC come into their own.
As a Flash developer it’s nice to know that many of the problems I’m trying to solve have been thought about and cracked a long time before Moock taught me how to code (thank you Colin, and your amazing O’Reilly books).
I’d been using a version of MVC that I’d cribbed from the back of Essential ActionScript 2.0 back in 2004, and had even ported it to ActionScript 3.0 as soon as I made the switch, using the new event model. It was pretty rough around the edges, but hey, it had become my baby now. It worked, and I was kind of proud of myself.
Then this year I made the leap of faith of switching to PureMVC, a framework for ActionScript development that was so popular it had started being ported to other languages such as Ruby, Objective C, etc. If it’s that popular, it must be good, right?
Is there a learning curve? You betcha. Is it worth it? I’m sure of it.
What is MVC?
It stands for Model-View-Controller, and is, IMHO, perfectly suited to the bear-trap that developing in Flash can quickly become.
At its simplest, MVC separates the state of an application (the model) from the display (the view). The controller takes input from the view, updates the model, and then broadcasts a notification that a change has happened. The views are then updated with the new state.
While it can seem like a long-winded way of developing, its structure encourages good development practices, helps avoid spaghetti code, and leads to more modular, reusable classes.
PureMVC has been a learning curve for both Shane and myself. However, the benefits it brings in stability and re-usability make it very, very worthwhile, and I’d recommended it to anyone bulding anything more complex than a banner.
But please don’t ask me to listen to Coldplay.