ActionScript 3.0 Design Patterns

Note: This is one of those posts that begs for reader comments. PHP is a much-loved language of mine, but I just don’t do the kind of applications that require PHP often. As a result, it stays on the shelf until I need it. So, while very familiar with PHP, I do not claim a high level expertise in it. However, judging from the online PHP discussions and PHP publications, lots of developers are well versed in the language. So, for you PHP’ers out there, your comments are welcomed. (Likewise if you’re not familiar with PHP, feel free to comment as well.)

PHP, My Old Friend

PHP has always been a developers programming language. From its inception, you could write PHP using Notepad or TextEdit and not have to worry about some cranky API or IDE. Alternatively, there are plenty of development applications for creating PHP, such as Dreamweaver. Further, you could write email apps as easy as a ‘Hello World’ example. Not only is PHP open source, it is constantly updated and improved by developers working on it because it is important to them. You can plunk it down on top of an Apache server (also open source) and use MySQL (also open source—but maybe not for long) for a database. It runs on Linux, Windows and on Mac OS (it comes standard with Macs as does an Apache server). Further, PHP 5 has real abstract classes! What’s not to like?
Read more…

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.

We finally finished judging the contestants and here are the results. Instead of having several categories for age, we decided to have only one because the ages did not have a great deal of range. Each of the winners happened to be from a different country, and so we can claim a true World Wide Contest. Congratulations to all! Download winning entries.

William Rafael de J. Ribeiro, Brazil
Our grand prize winner created an interactive “funny face” using the basic Decorator and adding a second component class for a face and four decorator classes for angry, normal, and sad eyes plus a smile decorator. By moving the mouse around you can see the face change and eyes move.



Todd Coulson, U.S.
Todd’s entry used a creative combination of elements to build a baseball diamond. The field was a simple rectangle, and it was decorated with an infield, the bases, a pitcher’s mound, boundary lines and players scrambling to the field. Todd is interested in adding to this foundation using other design patterns.



Timo Hannelin, Finland
Theoretical background for Timo comes from Katariina Nyberg’s article about phyllotaxis, fibonacci and the golden ratio. If we had a grand prize for the best algorithm, it would go to Timo. One algorithm makes an amazing amount of shapes—stars, triangles, squares, lines, shells, spirals…if you are lucky you will see almost all kinds of basic symbols. It also demonstrates that you can change a class in design pattern with a complex algorithm and it doesn’t faze it one bit.

Kevo X. Thomson, UK
Kevo had a very simple entry. By changing the x and y coordinates of the three concrete decorators, he was able to rearrange the images. Again, the change was made and there was absolutely no negative ripple effect. This is exactly what a good design pattern is supposed to do.

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.
Read more…

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.
Read more…

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.
Read more…

The problem in understanding the Hollywood Principle is that it is too often glossed over as a type of inversion of control. In most respects, the Hollywood principle is really about the direction of calls. Where it gets a little confusing is when you assume the natural order of programming is from bottom to the top, with the bottom making calls to the higher levels. At one time, much programming was “bottom-up” in this sense, but that’s been quite a while. Therefore, when talking about inversion, you may be wondering, inversion from what? In fact, the late John Vlissides (one of the Gang of Four) starts off a discussion of the Hollywood Principle, noting,

The Template Method pattern leads to an inversion of control known as the “Hollywood Principle,….” (1996)

As we know, Dependency Inversion is better understood as Abstraction Dependency—both higher and lower level components come to depend on abstractions. If we think depend on abstractions we have no need to even consider inversion. Doing so only confuses the issue. So, if we examine the Hollywood Principle, let’s do so in terms of what it does in its own right—what is its focus?

The Hollywood Principle holds that higher level components should call lower level components, but lower level components should not call higher level components.

So, if we take that focus of the Hollywood Principle we can better discuss its unique features. Is it related to the other principles of OOP? Of course it is, but let’s just focus on the point it makes.
Read more…