ActionScript 3.0 Design Patterns

Class Relations

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.

Let’s Get Acquainted

When one class holds a reference to another class, we can represent that by a line with an arrow pointing to the class that it has the reference to as shown in the Participant Relations diagram between Class A and the Interface/Abstract Class. If one class holds a reference to many objects in another class, a solid circle is placed at the tip of the arrow as shown between Class D and Class E.

That’s easy enough to see, but the real question is What’s going on? In other words, why would one class hold a reference to another? The answer lies at the core of Design Patterns: reuse. Class A is using the the Interface/Abstract class in some manner shape or form. Instead of creating its own interface, it’s reusing another one.

If you can remember that, you’re 90% of the way to understanding Design Patterns. You may recall the second principle of Design Patterns is

Favor object composition over class inheritance.

The relationship indicates that Class A has an interface. It doesn’t implement the interface, but through composition has the interface. Such a relationship is an acquaintance one. That means it has reused an existing object through composition.

In code, an acquaintance relationship can be many things. For example, consider the Prototype pattern covered in this blog. In this pattern the Client asks a prototype to clone itself. The pertinent code looks like this:

private var tDog:Prototype;
tDog = new Dog();
cDog = tDog.clone(tDog);

You may be thinking, That code creates an instance of the Dog class. Shouldn’t that be a creates relationship? If you look closely, you will see that it does not create an instance of Prototype but rather of Dog. The acquaintance arrow points to the Prototype interface; so, while it does instantiate a class, it is through the acquaintance with Prototype and not directly with Dog.

At this point, it’s very easy for the satellite to spin out of orbit when it comes to differentiating between an object reference and the creation of one class by another. However, as you look at more and more implementations of design patterns in code, you’ll see that where you have an acquaintance relationship, you’ll find that one class is using the other class through composition and not just creation. Using composition allows one class to incorporate the interface of another class and use its properties and methods. To use those properties and methods, the class that has another class through composition needs some kind of instantiation.

Think Composition

A lot of problems understanding participant relations in design patterns can be solved if you keep this in mind: Both inheritance and composition reuse a class interface. When you think composition, you almost force your code into good OOP. If you don’t use composition, what are your alternatives?

1. A big sequential program where you put all of your operations into one huge file. (Bad)
2. A big procedural program where call procedures as needed in one huge file. (Not good)
3. A big mother of all classes that spawns subclasses like of black widow laying thousands of eggs. (Scary)

Composition is favored because it is more flexible:

Composition is where, new functionality is obtained by assembling or composing objects to get more complex functionality.

I use the term flexible in this context to mean that composition is defined dynamically at run-time and helps keep each class encapsulated and to focus on its single task. Think of this—salt and pepper. Salt has one function and pepper has another. In composition you can select one or the other or both. With inheritance from class Spices, the salt and pepper may get mixed together, which may be fine and save time in some instances. However, sometimes you just want one or the other. You want each encapsulated and you want them when you need them; not cooked into the meal where you may get too much of one or the other or both.

Delegation

Delegation is a way to get the most out of composition. So, What’s delegation? According to Gamma, Helm, Johnson and Vissides, delegation requires two objects to handle a request. A receiving object delegates operations to its delegate. For an example of where delegation is used extensively, take a look at the Visitor design pattern. The operations performed on the concrete elements are always delegated to a Visitor object. When using delegation, a request to an object is forwarded to a delegate instead of by the object using an inherited operation. By using delegation, you can see that it makes it easy to compose behaviors at run-time and to change the way they’re composed. (When we discuss aggregate relations, you’ll hear more about delegation.)

Many References

In some patterns like the Observer (Chapter and Visitor, you will see the acquaintance arrow with the solid circle on the end. That means one object maintains many references another object. In looking at the discussion of the Visitor pattern, you can see the ObjectStructure class holds many references to the Element interface. Such multiple references are often handled by Array and Vector objects. For example, in the Visitor post, you will see:

1
2
3
4
5
6
7

//From ObjectStructure class
private var elements:Array=[];
 public function attach(element:IElement ):void
 {
          elements.push(element);
 }
....

That sets up the acquaintance between the ObjectStructure and the Element interface. Because it is a reference to an Array object, it holds a reference to all of its elements as well.

Where to Find Acquaintance Relations in Design Patterns

Of the 23 patterns in the Design Pattern catalog, only 7 have acquaintance relations separate from Client requests. They are:

1. Proxy
2. Adapter (Object version only)
3. Chain of Responsibility (Self-reference to Handler interface)
4. Command
5. Mediator
6. Observer
7. Visitor

The great majority of acquaintance relations in class diagrams are between the Client class and one of the design pattern participants. Some, like the Abstract Factory and Flyweight , have multiple acquaintance relations between the Client and other participants. Also, if you look at Client relations, you will see that they are primarily through an interface and not through concrete classes. (The Flyweight is an exception and the Visitor and Interpreter are partial exceptions.)

In the next post covering Design Pattern relations, we’ll look at aggregate relations and see how they compare to the ubiquitous acquaintance relations. By comparing them, we can better understand them both and what role each plays in the different design patterns.

No related posts.