Home >
About Advanced Flash Tactics
Advanced Flash Tactics or AFTs are techniques that come from deep within the Flash Art Of War, the oldest Flash military treatise in the world. Each AFT is designed to be quickly digested, usually only taking a few minutes to get up and running, and contains valuable information you can directly apply to your next Flash campaign. In this AFT I will go over - 3 Design Patterns Built Into AS 3.
I come across a lot of resumes for Flash Developers and two things always stick out, "I use OOP..." and "I know Design Patterns". These are pre-reqrisits for any Sr. Level Developer I would hire. During the interview, I usually ask the candidate to explain some patters they use in their day to day code. The most common answers of course are MVC (which technically can be considered an architectural pattern) and Singleton. This isn't a bad thing considering MVC and Singleton are two of the most talked about and highly debated patterns in the AS 3 community. However, there are quite a few other excellent patterns that get overlooked especially when you may be using them and not even know it. Lets take a quick look at what a Design Pattern is.
A Design Pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. - wikipedia
I view Design Patterns as a way to summarize a particular code system and help explain to other developers what is going on under the hood. You may have your own implementation of a particular pattern but as long as you stay within the technical description, other developers can look at your code and understand that you implemented X pattern and can begin looking for A, B, C, and D.
It is debatable whether or not knowing Design Patterns makes you a better programmer but there is no denying that it makes you a better communicator. A lot of the time I see people pick a Design Pattern and try to architect an entire application around it, MVC comes to mind. It is important to understand when creating a website or RIA that many Design Patterns can exist in the same space and may even help each other out. No application should or could be built on a single pattern. With that in mind I would like to introduce the following Design Patterns built into the core of AS 3:
** The following diagrams come from Jason McDonald's excellent Design Pattern Quick Reference chart which can be found in full here.**
Observer Pattern
The observer pattern (a subset of the asynchronous publish/subscribe pattern) is a software Design Pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
This is probably the single most used Design Pattern in AS 3. If you rely on the built in Event Class and Event System, which you basically can't avoid, you are setting up an observer. Of course this is a basic implementation of the pattern and can be enhanced by the developer depending on the needs of the application.
Facade Pattern
A facade is an object that provides a simplified interface to a larger body of code, such as a class library.
If you have ever used or created a component then you have used the Facade pattern. The best example of a Facade would be a video player component. The component may contain a video display and controls. The Video Player facade would hide the communication between the two and expose a set of public methods (APIs) like play, pause, stop and load that abstract the complex mechanics of the underlying classes. Facades are probably the second most used pattern in all of my applications. It represents a great way for simplifying complex code systems especially for shared code or open source projects.
Proxy Pattern
A proxy, in its most general form, is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate.
The Loader class is a great example of a Proxy class. When you create a new Loader it has all of the properties of a DisplayObject like x, y, width, height, and alpha but it really is a stand-in for an image or swf that has not been loaded. You can add the Loader to the Display List and change its values so that when the assets gets loaded it will take on the values of previously configured properties. Proxies are a great way to deal with data or classes that are not loaded or active yet.
As you can see Design Patterns are all around you. If you are like me and come from a designer background, wrapping your head around Design Patterns may be a little tricky. I have spent several years reading, studying and discussing them before becoming somewhat comfortable with the topic. I have only just begun to scratch the surface. To help, here are two resource I used to get started:




Facebook Application Development
A sweet-n-juicy article... it's great to hear/see someone champion digging into topics that might initially cause some discomfort but typically leads to some nice discoveries (e.g. understanding / appreciation) in architectural constructs.
To add my .02 to the mix. I've had a few projects recently with 'plug-in' capability as a requirement... which has lead me down the Template and Factory Method design pattern path.
Hi
At the college I had to learn Design Patterns, too. First time I had got a couple of Problems to understand the abstract ideas of each pattern. Then I read the Head First Design Patterns Book and it really clearify the most things for me:
http://www.amazon.de/Head-First-Design-Patterns-Freeman/dp/0596007124/ref=sr_1_1?ie=UTF8&qid=1250144693&sr=8-1
I don't want to do advertisement on this blog, but this book is so good for beginners in this topic
Design patterns are a categorisation of various techniques that I personally believe good developers with OO training will use by default to solve common problems.
They are helpful to have so that we developers can communicate problematic scenarios and solutions to each other meaningfully. However, I would be weary of thinking that knowing them all will lead to some kind of nirvana.
If I was interviewing a developer and wanted to test their OO knowledge, I'd get them to draw me up a object orientated solution to a problem I've defined. I'd also be curious as to their approach - top down (personal preference) or bottom up. Being able to spout off the features and use cases of a handful of design patterns doesn't imply to me that a developer can apply sound OO principles to a problem.
Regardless, good post - well explained.