ActionScript 3.0 Design Patterns

As promised, we have a survey ready for everyone who would like to provide feedback on the Saturation series. It only takes 5 clicks, and if you didn’t feel like writing a comment, you can do this one in only 5 clicks of your mouse. By clicking 4 radio buttons and 1 submit button, you voice will be heard loud and clear or quietly and muted—whatever your preference. And remember, if you want to provide more details of your preferences, feel free to add a comment either here or in Saturation Feedback: Part I. Click the survey belly button and see what may become an ActionScript 3.0-PHP Project:

We have a tie with both Creational and Structural Design Patterns! Do the 5-click survey and break the ties! (Easy!)

Choose the next Saturated Design Pattern:

• Creational: Abstract Factory, Builder, Factory Method, Prototype
• Structural: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

Every now and again we like to survey our readers about one thing or another. This is the first part: an open-ended invitation for comments about the first installment on the Saturation series. The second part will be a short structured survey requiring nothing more than a few clicks. A while back I thought that a saturation plan would be a good idea—take a representative design pattern and look at it in minute detail. The first one was a Behavioral type design pattern, the Strategy pattern. I selected it because it is one of three patterns that is dependent on delegation (extreme composition). Now that it’s been saturated, what do you think? Good idea? Bad idea? Don’t give a rat’s …? I’d like to hear some unrestrained feedback in the comments section.

What’s Next?

Well, as far as the Saturation Series is concerned, I’ll be working on one from either the Creational or Structural categories. If you have any preferences, just shoot us a comment. Here are the choices:

Creational

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

Structural

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

These patterns are from Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (AKA The Gang of Four [GoF]) We covered all of these patterns either here on our blog or in our book. Don’t forget to say why you’d like a certain pattern saturated. We always read all of our comments (except for spam and sales pitches.) Usually, we reply to every comment, but in this case we’re going to focus just on listening to what you want.

What are you waiting for? Get commenting!

I just got back from the SPLASH (OOPSLA) conference in Reno. To be honest, I wasn’t looking forward to it because I had to present a paper to the Educational Symposium, and just about everybody there had a Ph.D. in computer science and I was going to be eaten alive. Besides, the usual group I do things with (Killer Examples) had decided not to hold their usual session and I didn’t know anyone in the Educational Symposium. To give you an idea of the session I was in; here are some topics:

• The impending ordinariness of teaching concurrent programming
• Mutation Analysis vs. Code Coverage in Automated Assessment of Students’ Testing Skills
• Compiler Construction With a Dash of Concurrency and an Embedded Twist
• Learning OOP with Dynamic Languages: Adding Concrete Strategies to a PHP Strategy Design Pattern
• Manifesto: a New Educational Programming Language

When someone is talking about the “ordinariness” of “concurrent programming” and I had no idea what concurrent programming was, I was a little rattled. However, everything was so interesting that I soon forgot about my own concerns and really got into these other topics. The big deal that hit me between the eyes was concurrent and parallel programming. (One undergraduate student had a presentation on CUDA, which is used in learning concurrent programming—it took him three hours to crank out “Hello World!”) When my turn came, it worked out well, and I survived and even had a good time. The presentation after mine was by three guys who were discussing the process of developing a new language called Grace. SPLASH has a humbling effect. (Click the link below and learn how I met one of the Gang of Four.)
Read more…

When I hear “dependency” and “design patterns” in the same sentence it usually means the latter is at work reducing the former. However, in the case of dependency injection, it is an important part of both design patterns and unit testing. Chandima has mentioned it in a discussion of the Iterator pattern, I’ve a post on the dependency inversion principle, which is a close cousin. However, the concept of dependency injection is one which could use a post that focuses on it and not the different patterns that may use it. So here goes.

The go-to guy in dependency injection is Martin Fowler, but I first became aware of it in one of Miško Hevery’s posts, and it was the topic of his discussion at last year’s OOPSLA meetings in Orlando, Florida. In looking around for different takes on dependency injection (or DI as all the cool kids call it), one of the better ones was by Griffin Caprio on an MSDN page. Caprio uses a Factory example, but alas, it’s an Abstract Factory, and I get the heebie-jeebies just looking at the class diagram. So explaining DI using an Abstract Factory is like explaining simple arithmetic using quantum physics. (Just clench your teeth and click the link to get the rest.)
Read more…

Back in 2007 I wrote a rant called Let’s Get Rid of Conditionals, and as you might imagine it stirred up the readers of this blog. It was based, in part, on my experiences at the 2007 OOPSLA meetings in Montreal. The intent was to generate discussion on the matter and by that measure, it was successful.

Since that time, several other posts on the use of conditional statements have cropped up in posts on the Strategy pattern, and here again I take up the topic of avoiding overuse of conditionals. To get started, I made some minor adjustments to the example program so that you can see something other than trace() statements. (Take it out for a spin: click the Play Button. You can download it as well…)
You will see that the concrete strategies are similar, but you can imagine more complex and different algorithms in the individual concrete strategies. However, the focus of this post is on the conditional statements—or the total lack of them in the Strategy design pattern. (Continue to see what’s wrong with conditional statements.)
Read more…

One of the most sensible principles in the GoF tome is to favor composition over inheritance or, as Gamma, Helm, Johnson, and Vlissides put it:

Favor object composition over class inheritance

Object composition is an alternative to inheritance. However, they point to a very precise kind of inheritance that causes most of the problems they’re talking about. For example, suppose we have a car object and we want a navigation system for it. The approach that GoF is concerned about is where the developer creates a subclass of the car object to include a navigation system or create a navigation subclass with added car functionality. Figure 1 shows the approach to inheritance they argue leads to tight coupling:

After using composition this kind of inheritance may seem heavy-handed, but it is the kind of reuse that Gamma, et al, are suggesting that is better handled by composition. GoF use an example of a Window object (a regular glass window—not one that Bill G. owns) obtaining a rectangle shape by becoming a subclass of a Rectangle class. In that way, the Window is a rectangle. The logic is that, since you have a rectangle anyway and windows are rectangles, just make a subclass of Rectangle and give it Window properties. In that way, you reuse all of the rich functionality of the rectangle without having to re-invent it in a new Window class independent of the Rectangle class. (Turn the page to find out more about composition and delegation.)
Read more…

A recent comment by Lukas Buenger in the Saturated Strategy series about the role of the Context class got me thinking—exactly what does the Context class do? The Client requests a ConcreteStrategy, and the algorithm does just ducky without a Context. The client has delegated the behaviors to the Strategy interface and the concrete strategies can be typed to the interface; and Bob’s your uncle!—you have delegated behavior. Is this not composition that is favored over inheritance? In fact, the Freemans in their wonderful book, Head First Design Patterns illustrate delegation in a a Strategy pattern with their quacking and flying duck example. However, their Strategy example has no Context class.

Why the Context?

In the current series on the Saturated Strategy the example uses different navigation strategies to illustrate the design pattern. To instantiate one of the concrete strategies the client uses the following code:

private var conStrat:Context=new Context(new ConcreteStrategy())

The variable conStrat represents any concrete strategy request. However, as you can see, it is not typed as a ConcreteStrategy but as a Context object. So where is the ConcreteStrategy instantiated? In the Client or in the Context? As a private variable, you know conStrat is encapsulated in the Client; however, what about the concrete strategy? (Click below to continue on to an experiment)
Read more…