ActionScript 3.0 Design Patterns

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…