Monthly Archive for March, 2009

Design Pattern Principles for ActionScript 3.0: The Open/Closed Principle

Published on March 31, 2009 in Design Patterns at Work, Examples, OOP and Principles. by William B. Sanders 2 Comments

bucketrule
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.

Continue reading ‘Design Pattern Principles for ActionScript 3.0: The Open/Closed Principle’

ActionScript 3.0 Builder Design Pattern Part I: Controlling Creation

Published on March 17, 2009 in ActionScript, Builder and Design Patterns. by William B. Sanders 6 Comments

Changing How a Composite Object Gets Created

In both our book and on this blog, Chandima and I have tried to clarify and simplify ActionScript 3.0 Design Patterns and yet keep them accurate and, whenever possible, practical. After reviewing many, many Builder examples, I was surprised to find pieces missing in several instances, and while the examples may have combined elements (such as the Client and Director); others simply left out crucial components. (Who could forget bad, bad Leroy Brown who looked like a jigsaw puzzle with a couple of pieces gone?)

Given this state of affairs, it occurred to me that this pattern might be tricky; however, after working up an example, it turns out to be relatively simple and useful. Nevertheless, it’s not quite as simple as some, such as the Strategy or Factory Method, and so the discussion of the Builder is in two parts. This first part provides a clear overview so that you can easily see how the different components work together and starts a practical project., The second part (in a separate post) removes the abstract trace statements and displays actual content on the stage in a useful way. This will be to see if video, SWF, text, and images can be usefully integrated using the Builder.

Builder Overview

When you first look at the Builder class diagram shown in Figure 1, you might think it looks a lot like the Strategy pattern. Well, the class diagrams are similar, but the intent is very different. Also, you’ll find that the little Product class is hugely important.

builder
Figure 1: Builder Class Diagram
Continue reading ‘ActionScript 3.0 Builder Design Pattern Part I: Controlling Creation’

ActionScript 3.0 Developers: The Children’s Table Revisited

Published on March 15, 2009 in ActionScript. by William B. Sanders 8 Comments

A little less than a year ago I published a post (really a rant) on this blog entitled ActionScript 3.0: Not At the Children’s Table Anymore. It was directed at those who looked down on us ActionScript 3.0 developers as serious OOP and Design Pattern programmers. It was also an invitation to take up the challenge to go beyond Timeline programming and use all of the new language tools and structures available in Flex Builder and Flash CS3 and CS4.

My enthusiasm was based on my great admiration for ActionScript developers and my firm belief that they were just as capable as any Java, C# or C++ programmer. That faith has never faltered based on what I have seen on this blog and in ActionScript 3.0 creations. In fact, if anything, it has been reinforced. ActionScript programmers take a back seat to no one.
Continue reading ‘ActionScript 3.0 Developers: The Children’s Table Revisited’

Design Pattern Principles for ActionScript 3.0: Loose Coupling

Published on March 12, 2009 in ActionScript, Design Patterns and Principles. by William B. Sanders 3 Comments

bucketruleProbably the best place to start a discussion of loose coupling is with an analogy. Suppose you’re on a trip away from home and you want to buy a gift for your child. You don’t know the town you’re in that well, and so you ask the receptionist at your hotel where you can find a toy store. The receptionist suggests a nearby store, and you go there. It’s a big toy store, and so you locate a clerk to help you find the toy you want. After showing you several toys of the kind you’re looking for, you proceed to select one and purchase it. You ask the clerk if you can have the toy gift-wrapped, and she takes the toy to the back room and has it wrapped for you.

The process to locate, purchase and have a toy gift-wrapped involves interacting directly with two people—the hotel receptionist and toy store clerk. A third person may have gift-wrapped the toy, but you don’t know and don’t care. All you care about is getting the toy and having it gift-wrapped. The process is smooth because you are loosely coupled with the people with whom you interact.

You Can’t Handle the Truth

Let’s suppose that the receptionist at the hotel just found out that his girlfriend ran off with a traveling design pattern developer and is heart-broken. You don’t need or want to know that. All you want from the interaction with the receptionist is the location of the toy store. You want loose coupling with the receptionist. Knowing about the receptionist’s internal turmoil won’t get you what you need and may needlessly complicate things because you too are a traveling design pattern developer. Interaction between hotel receptionists and hotel guests is well defined and restricted.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: Loose Coupling’

Design Pattern Principles for ActionScript 3.0: Encapsulate What Varies

Published on March 10, 2009 in ActionScript, Design Patterns and Principles. by William B. Sanders 4 Comments

bucketruleSometimes a concept or principle is so simple that it can fly under the radar and no one understands it. For me, at least, this was the case for the OOP principle, encapsulate what varies. In the context of a program, encapsulation is the process of hiding the internal mechanisms and data structures behind an interface. To use the encapsulated operations (object, component), all the developer needs to know is what the component does. Then when the developer needs the component, all of the operations hidden in it are accessed by some kind of request—composition, inheritance or even simple instantiation.

So far so good. Encapsulation is pretty clear, and by the time you’ve decided to tackle design patterns, you should have some idea of encapsulation from OOP principles. The tricky part may be in understanding what is meant by separating elements that you expect to change and those that you expect to stay the same and encapsulate those that change. For this principle, we’re only interested in those elements that may change. Obviously, variables and data change values all the time, and so if we try to encapsulate everything that changes in a program we can quickly become entangled in a swirling flux of mutable elements.

What May Change?

In a recent Lunch Bucket pattern post that loaded SWF files, I noted that I was thinking about adding modules that would load XML files and text files. In other words, I was thinking about what may need to be changed in the program. So when discussing change the principle is not pointing to variables and data but adding components to the existing structure.

The added components are the change referenced in the principle.

All I really need to add (change in the program) is an algorithm to load XML files and another one to load text files. By choosing the Strategy pattern, I can easily add this new functionality by implementing the strategy interface with a new algorithm. The Strategy design pattern is specifically designed to handle change by adding algorithms; therefore, in that pattern algorithms vary and so they are encapsulated.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: Encapsulate What Varies’