ActionsScript 3.0 Design Pattern Relations Part II: Aggregation

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:

Figure 1: Aggregator and Aggregatee

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

In looking at the aggregate relations between the Context class and State interface in the State example, we see the following aggregation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class Context
	{
		private var stoph:State;
		private var moveup:State;
		private var movedown:State;
		private var moveleft:State;
		private var moveright:State;
		private var stateNow:State;
		public var chopper:Sprite;
 
		public function Context( chopper:Sprite )
		{
			this.chopper=chopper;
			trace("State is here");
			moveup=new MoveUp(this);
			stoph=new Stop(this);
			movedown=new MoveDown(this);
			moveleft=new MoveLeft(this);
			moveright=new MoveRight(this);
			stateNow=stoph;
		}
		public function upMove():void
		{
			stateNow.doMoveUp();
		}
...end snippet

So what’s getting aggregated? In this instance the entire State interface and all of its implementations (classes) and methods are aggregated in the Context class. All of the requests coming from the Client are delegated to the State through such aggregation.

At this point you may better understand GoF’s statement,

Aggregation implies that an aggregate object and its owner have identical lifetimes.

The aggregate object is that created in the Context and the owner is the State interface and implementations. The Context creates the aggregate object by gathering up all of the concrete states. When the Client makes a request, it uses an instance of the Context:

private var contextNow:Context=new Context(chopper);

The instance, contextNow, essentially is the aggregate object. If you change the State implementations, it doesn’t matter because the Client makes the requests through the Context that creates an aggregate instance. That means if you change the implementations of the concrete States, everything still works because the requests are all through the Context class. As long as an aggregate relationship exists between participants in a design pattern, the aggregator creates an aggregate instance. With requests made through the aggregator, you decouple the request and the objects that carry out the requests. Further, through aggregation you can reuse objects all you want arranged in the way you want to employ them.

Closely Related Participants

You will find aggregate relationships in several design patterns, and the actual ActionScript 3.0 encoded aggregation has many faces. In coming to understand aggregation, take a look at several of the following classes that contain aggregation relationships.

• Builder
• Bridge
• Composite
• Decorator
• Flyweight
• Command
• Interpreter
• Memento
• State
• Strategy

One of the more interesting uses of aggregation is where the child classes aggregate the parent class or interface. You can see this in the Composite and Decorator patterns. Likewise, you will see many different ways that the aggregation process is designed to structure the relationships between design pattern participants. By looking at the code in different examples aggregation you will begin to see what aggregation means.

Aggregation for Change

After posting the State example with the Helicopter (extension of Sprite class) jumping around the screen, we received several comments on improving the design. By having a State design pattern in place, that should not be too difficult to change the states for the Helicopter. The structure can remain the same, but not only could we substitute just about any sprite for the Helicopter, we could change the algorithms using the current interfaces without touching the fundamental design pattern. So in the next post, we’ll look at the Helicopter movement with an eye to making it more state-like while maintaining the current structure, even adding helper classes if we want. As always, we value your comments.

The ActionsScript 3.0 Design Pattern Relations Part II: Aggregation by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. ActionsScript 3.0 Design Pattern Relations Part IV: Creation
2. ActionsScript 3.0 Design Pattern Relations Part I: Acquaintances
3. ActionsScript 3.0 Design Pattern Relations Part III: Inheritance