OOP Techniques for Flash and Flex Developers
A Three-Question Survey
I’m working on a new post about ActionScript 3.0 Design Patterns at work. To help get an accurate measure of what folks are doing in the ActionScript work world, I put together a simple survey. The survey is made with radio buttons and check boxes; so it only takes a minute to fill out. Click below to take the World’s Easiest Survey:
ActionScript Design Patterns at Work Survey
We thank you in advance, and when we get the post up, you’ll see the results from the survey.
The Naked Flash Designer
As a general way of making sense out of projects, they are divided into design and development. The design component usually means graphic design, but it can also include the UI (HCI) and information design—the kinds of things Edward Tufte talks about. In other words, design refers to everything that the user actually sees and interacts with. Those involved in design must expose their work to the user. It is in no way shrouded, and hence naked.
Developers’ work, on the other hand, has better cloaking than a Romulan space ship. If something goes wrong, and the program blows a gasket, the user can see a problem, but if things work, even in the most pedestrian program, the programming is invisible. The entire program can be one hack piled on top of another (as was the case with ActionScript prior to ActionScript 3.0), and no one would ever know. So, we programmers are safe to write any kind of code we want, and as long as it works, everyone is happy.
In many respects, most projects are design ones. The look, feel, navigation and interaction of a program makes or breaks it. A beautifully programmed project isn’t worth a bean if it looks poor, is difficult to navigate or interacts awkwardly with the user. Conversely, if a program looks and acts good, no one cares about what’s under the hood as long as it works.
Continue reading ‘The Naked Flash Designer and the ActionScript 3.0 Algorithm Dope’
Easy to Find
We got to the point where the posts on the Principles of OOP and Design Patterns and the discussions of introducing Design Patterns to the workplace became so numerous that they were difficult to locate on the blog. This is the first index that we have, and as we continue to grow, we’ll have to add more. (We are certainly nearing that point with MVC and Pure MVC posts.) So, in the “Categories” section of our blog, we’ll be adding indices as needed. Look for the Index category to locate all indices.
Continue reading ‘Index: ActionScript 3.0 Design Patterns Principles and Design Patterns at Work’
The final principle we’re going to examine for the Lunch Bucket Rules series is the Single Responsibility Principle. Succinctly stated, it means that each class should have one and only one responsibility. At the base of this principle is the idea that if you make a change, you are less likely to run into a problem if each class has a single responsibility. The same principle is expressed as, each class should only have a single reason to change.
In our book, we discuss this principle briefly (pg. 443). The MVC design represents three clear areas of responsibility—Model, View, and Controller. Each responsibility is clearly spelled out, and each of the three elements in the framework sticks with its own responsibility. That’s not a bad place to start as far as a getting a general sense of what this principle means.
Simple Never Is
In searching around for information about the Single Responsibility Principle, I came across a short post by David Chelimsky. In that post he cites the following quote:
In procedural programming, a process is expressed in one place in which a series of instructions are coded in order. Whereas in OO, a process is expressed as a succession of messages across objects. One object sends a message to another, which does part of the process and then sends a new message off to another object, which handles part of the process, etc. You modify a process by reorganizing the succession of messages rather than changing a procedure.
Ooof! That quote knocked the wind out of me because of all of its implications. It’s saying that when you make a change, your main focus is on rearranging responsibilities encapsulated in classes instead of re-writing a procedure. This forces the developer to ask, What responsibility does each class have? If each class has a single responsibility, that makes life a lot simpler. On the other hand, classes with multiple responsibilities may be ripped up or cause problems elsewhere because they can be changed in more ways than one and do more than one thing, wrecking unpredictable havoc.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: Single Responsibility Principle’
An Enigma Wrapped in a Clear Casing
The Decorator Design Pattern is an enigma wrapped in a perfectly clear casing. I can think of fewer design patterns that are clearer in terms of what they do or seem more practical. By using concrete decorations, you can change an object without touching its structure. You can pick and choose what features you want to add, and your central object (or Concrete Component) is untouched. You want to add another feature? ¡No problema! Just add another decoration. Likewise, if you want to remove an unwanted feature, just remove the decoration you no longer want. All of this changing is accomplished without touching the object all the while the object is effectively changed by the decorations. So updating is simply a matter of changing decorations and/or adding new components to be decorated. (Download all files for program here )
In our book, the most real world practical example was a car dealership where different models of hybrid cars (Components) were set up with different accessories (Decorators) to arrive at a final price. As different models of hybrids became available, they could be added to the components and as different accessories came and went, they could be added to the program without having to disrupt the structure of the program. The pricing of the car was based on both on the base price (Component) and the whistles and bells (Decorators) the buyer selected. Once set up, the site is easy to maintain, update and reuse in a different context.
In this post we want to provide a simple yet usable example that can be modified for your own needs. Many of the simple examples we’ve seen (or created ourselves) have made extensive use of string and numeric variables and/or trace output. Given the fact that practical applications make extensive use of such variables, there’s nothing wrong with that. However, we’ve found that the most difficult part of creating design patterns with ActionScript 3.0 is in making use of graphic materials and movie clips.
Continue reading ‘ActionScript 3.0 Easy and Practical Decorator Design Pattern’
Microblog Tweets
Bill Sanders
Recent Comments