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.

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…

For those of you who have developed applications where a reference drills down through a series of movie clips, the Least Knowledge Principle may seem a bit harsh. It is very easy and even shows a semblance of foresight and organization to arrange operations in a movie clip set to have each movie clip do one thing in a complex object. To get something working, though, you do not want to rely on drill-down references that visit each of the many movie clips. Statements such as,

myMC_high.myMC_middle.myMC_lower.myMC_lowest.DoSomething()…

break the principle of Least Knowledge because it implies that each has some knowledge of the inner workings of the others. Likewise, anyone who has spent much time with JavaScript and the Document Object Model (DOM) knows that many of the objects have some hefty drill-downs in references. According to the Least Knowledge Principle, these are all ways to ask for trouble. Let’s see why.
Read more…

Most of what we mean by the Dependency Inversion Principle has been discussed either in describing what a design pattern does in terms of relating components to one another or implied in other principles. However, I’ve found that the Dependency Inversion Principle acts as a helpful reminder to keep things abstract in working with instances that request functionality or extend a base class.

Unfortunately, the concept of inversion is only half the story and is used in reference to programming structures where a higher-level module depends on a lower-level module. One might be led to believe that the inversion occurs where lower level modules depend on higher-level modules only. Actually, the principle holds that

all modules of a program should depend on abstractions

Maybe a better name for the principle would be the Abstraction Dependency Principle. In any event, program modules should all depend only on abstractions. If you look at Figure 1 you can see a simple example where a Client instantiates a concrete class but depends on the abstract class for typing. Further, the concrete classes depend on the abstract class for implementation. Aggregations and associations would depend on the abstract base class instead of the concrete classes as well.

Figure 1: Depending on Abstractions
As you can see in both the diagram and code snippets, all dependencies are on the Abstract class. That’s what the principle means at its core. It’s not a difficult one, and it overlaps with lots of other principles we’ve discussed on this blog and in our book.
Read more…

In looking for details about the Dependency Inversion Principle, I came across an article by Robert C. Martin in which he discusses a situation where one software developer looks at another’s application. Because I’ve had similar experiences, along with the exasperation developers feel for such comments, I thought I’d include it here—paraphrased as it were. He beautifully portrays the adolescent sniveling where the other’s comment is all too often,

That’s not the way I would have done it…

In several states I believe such comments are grounds for justifiable homicide. Not only is that kind of comment indicative of a certain type of nastiness, it is generally not helpful. Being as immature as the next guy, my general response is usually something like,

Okay smarty, how would you have done it?

This kind of brain-dead twittering misses the crucial point of what is good software design? Maybe I did indeed do it all wrong, but by what criteria do we judge good design? To some extend the answer lies in all of the discussion about OOP and Design Pattern principles we’ve covered on this blog and in our book. Martin provides a nice set of good design indicators that encapsulate much of our discussions.
Read more…

In the little AIR menu with the 10 principles one of the clearest is the Open/Closed Principle. At one time this principle suggested that all updates be created using an implementation or extension of virtually any class. That could get tricky, especially if someone understood that to mean implementing an update or extending a subclass. However, later, the extension came to mean the extension of an abstract base class. In other words the interface is extended but never modified. Given these caveats, we can understand the basic principle as it is now understood:

Classes should be open for extension but closed for modification.

Easy to Take to Work

(Note: In talking about a program and changes, we’re not including the Client class. It just makes requests, and you can add requests and change them all you want in the Client.)

The idea that when you want to change a program, the only way you are able to make changes is by extension may seem a little restrictive. However, what the principle is really doing is providing a way to make changes without having to rewrite the whole program. The dictum, New behaviors are only available through extension should not be phrased in a way to make it sound like it’s tying your hands. Rather, it should say something like,

Hey! The Open/Closed principle makes it easy to add new behaviors without having to mess up your whole program.

Read more…