ActionScript 3.0 Design Patterns

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…

I’m tempted to say that aggregation is a stronger form of acquaintance, and that wouldn’t be far from wrong. In fact, in certain contexts it may be perfectly correct. Gamma, et al point out that the differences between the two is a matter of intent rather than explicit language mechanisms. That makes it a little tricky simply to show some code and pronounce, “See that’s what an aggregate looks like.” So bear with me as we look at aggregate relations.

Conjoined Participants

As can be seen in the red arrow symbols in the Participant Relations diagram at the top of this post, an aggregate relation is indicated by an arrow with a diamond at its base. The GoF illustrate the relationship as shown in Figure 1:

The Aggregator creates an aggregate instance of the Aggregatee. As noted, GoF point out that no single code set can demonstrate what an aggregate relationship looks like, but I think that we can get a start by looking at a fairly simple relationship in the State design I created so that we could discuss both aggregate relations and delegation. (The Strategy design also provides a good example of aggregation with delegation.)
Read more…

This post is the first in a series where I hope to discuss all of the key relationships between classes in Design Patterns. To help identify posts in this series I’ve created a general diagram with all of the different kinds of relationships between classes. I did not include the boxes for pseudo-code or divide the classes into areas for operations and properties. The purpose is to focus on the relationships in this series. You may have noticed that the chart is titled, Participant Relations, and by Participant, I’m referring to any class or interface in a design pattern using the Gang of Four’s terminology. In order to help you quickly see the current relationship topic, the Participant Relations diagram shows the currently discussed relations in red.

UML Controversy: Tempest in a Teapot

In this and subsequent posts, I’m sticking with the notations used by GoF. If you’re into UMLs, you’ll know that GoF actually use a few non-standard notations, but I think that by using the ones GoF use our discussion will be less confusing. If you’re interested in a more standardized UML notation take a look at Judith Bishop’s book, C# 3.0 Design Patterns (O’Reilly) on pp.4-5.

GoF discuss abstract classes and interfaces as interfaces. So, in an example where an abstract class is used, you’ll see an italicized class name. If an interface is used, you’ll see the same thing. In some respects this can be quite helpful in that when you see any italicized text in a class diagram you’ll think interface and know that you can develop your own design pattern using either an abstract class or interface.

The inheritance symbol, that we’ll be covering in detail in a later post, is used to denote both inheritance (extends) and implementation (implements). This is consistent with GoF’s interchangable use of abstract classes and interfaces and their notations. So bear with me on these idiosyncrasies and help focus on the relationships between participants.
Read more…