ActionScript 3.0 Design Patterns

Aggregation Magic

In discussing aggregation, the Gang of Four left a lot of loose ends, and the relationship can be difficult to grasp. It’s something like an acquaintance but is stronger. Nevertheless, acquaintances can be just as strong but not be aggregations. So is it really that important to distinguish between aggregation and acquaintances? In most cases the distinction is important because while many similarities exist between them (just as with men and women), the differences change the character of the relationship. Gamma et al point out,

Aggregation implies that an aggregate object and its owner have identical lifetimes, (p. 22)

but that description brings up other questions. We can assume that an aggregate object is the combination of two objects bound through aggregation. However, what is its owner? In Part I of this series, you saw that the Bridge pattern is made up in part of an orthogonal component bound by aggregation. That’s pretty clear, but how is that component owned? Does that mean the parts that make up the component are the owners? If one or the other of the aggregated objects (classes) ceases to be; so will the other one. Thus, the parts are the owners. However, another way of looking at ownership in an aggregate relationship is by examining it parts.

The aggregation relationship is characterized by the Aggregator and Aggregatee as shown in Figure 1.

In this model, it would appear that the aggregator is the “owner.” It defines the relationship by holding a reference to the aggregatee.

The Orthogonal Bridge

The “aggregateinstance” in Figure 1 is the “bridge” in the Bridge pattern, and it is the orthogonal component discussed in detail in Part I of this series. The next step in understanding the Bridge design pattern is to implement it. The alarm clock provides a clear way to see the relationship between objects linked by an aggregation that makes up an orthogonal component. Figure 2 show the files for the implementation arranged in a File Diagram:

This Bridge example is quite simple and easy to understand as a Bridge pattern. The two interfaces are made up of an abstract class (IAlarmClock) and an interface (IAlarm.) You can think of the physical alarm clock as an instrument that keeps time and the alarm as a sound it makes to generate an alert. The clock and its alarm can vary independently but work in conjunction. The clock has a time-keeping function that can be used to call the alarm when needed. In the example, the clock implementation is that of an analog clock that rings a bell and a clock radio that plays Ride of the Valkyrires (Wagner’s Walkürenritt). It’s easy to add a different clock implementation (a Cuckoo clock, for example) or a different alarm—a rocket ship blasting off if you wish. The following two buttons will download and Play the example for you:

The clocks do not update, but they should display your accurate local time. You can easily put a Timer object in the program to make the clocks work like running clocks. Likewise, while I did not place an alarm setting function in the clocks, I placed an alarm testing button. That’s so you wouldn’t have to sit around waiting for the alarm to ring. However, it wouldn’t be difficult to do so. In fact if any of you want to place a running clock in the pattern by extending another implementation from the IAlarmClock abstract class, I’d very much like to see it, and I’ll display it on the next blog entry in this series—same with implementations to the IAlarm interface. Okay so where do we start with implementing this pattern? Read on.
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…