Make an Orthogonally Designed Alarm Clock

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.

Figure 1: Does the Aggregator own Aggregatee?

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:

Figure 2: Bridge File Class Diagram

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.

The Reversed Engineered Implementation of the Alarm

We might as well start at the ending. In fact I knew where I was going (driving backwards) because I had a good sense of the Bridge pattern; so it wasn’t starting without a roadmap. I wanted to start with an alarm implementation. Getting the sounds was easy (check out Project Gutenberg and the old standby, Flash Kit for mp3 sounds). However, I always have to go back and re-learn the procedure for playing sounds since I don’t use sounds that much. The following implementation was used for both with the only difference being the MP3 selected:

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
27
28
29
30
31

//Clock radio IAlarm implementation
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.media.Sound;
	import flash.media.SoundChannel;
 
	public class RideAlarm implements IAlarm
	{
		private var aChannel:SoundChannel;
		private var aSound:Sound;
		private var aRequest:URLRequest;
 
		public function alarmPlay()
		{
			aSound=new Sound();
			aChannel=new SoundChannel();
			aRequest=new URLRequest("alarms/rideOfValkyries.mp3");
			aSound.load(aRequest);
			aChannel=aSound.play();
		}
		public function alarmOff()
		{
			if (aChannel)
			{
				aChannel.stop();
			}
		}
	}
}

It’s pretty simple. All I really needed were methods to play the alarm and to shut it off. From here I backed into the IAlarm interface:

1
2
3
4
5
6
7
8
9

//Alarm interface
package
{
	public interface IAlarm
	{
		function alarmPlay();
		function alarmOff();
	}
}

I don’t mean to sound like any idiot can get this stuff, but sometimes we make things harder for ourselves than we should—especially when it comes to design patterns. (Yes, I know this is a simple example. It’s supposed to be, but if you can grasp the pattern concept, then you’re good to go for more complex implementations of the same pattern.)

Alarm Clocks

Early on I decided that the alarm triggers in the clocks would be buttons rather than a timing trigger. The concepts of triggering the alarm are identical—an event does it. It really doesn’t matter whether the event is one caused by a Date method or MouseEvent; so I used a MouseEvent so that I could play with the clock and the alarm during development.

For the clocks, I definitely wanted to start with the abstract class from which the clock implementations would come from. First, I had to make sure that the abstract class held a reference to the IAlarm interface. Second, I had a good idea of what methods were needed even though their implementation would vary. The following listing shows the abstract class, IAlarmClock:

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
27

//Abstract class for Alarm Clock
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class IAlarmClock extends Sprite
	{
		protected var timeNow:Date=new Date();
		protected var alarm:IAlarm;
 
		public function curTime():Sprite
		{
			throw new IllegalOperationError("Must override");
		}
 
		public function doAlarm():void
		{
			throw new IllegalOperationError("Must override");
		}
 
		public function offAlarm():void
		{
			throw new IllegalOperationError("Must override");
		}
	}
}

I knew that the Date object would be needed for the clocks because the class has properties for the hours and minutes needed for the clock hands and “digital” display. The IAlarm instance, alarm, established an aggregate relationship between the abstract class and alarm interface.

The implementations of the curTime() method were very close to being constructor functions. The idea of the method originally had been to update the time in hours and minutes from the parent class timeNow property. However, I ended up using it for building the clock and setting the hands or “digital” values on the clocks as well as getting the time and instantiating the alarm implementations.

Unlike the alarm implementations, the clock implementations were very different. One was used to set up an analog clock and the other a “clock radio.” I had drawn the face and the clock hands and saved them as Sprite classes, ClockFace, Hour and Minute. The following two listings show these implementations:

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
27
28
29
30
31
32
33
34
35
36
37
38

//Analog clock: IAlarmClock implementation
package
{
	import flash.display.Sprite;
 
	public class BellClock extends IAlarmClock
	{
		private var minHand:Minute=new Minute();
		private var hrHand:Hour=new Hour();
		private var cFace:ClockFace=new ClockFace();
		private var clockUp:Sprite=new Sprite();
		private var adjust:uint;
 
		public override function curTime():Sprite
		{
			alarm=new DingAlarm();
			cFace.x=100;
			hrHand.x=200,hrHand.y=100;
			hrHand.rotation=(timeNow.hours+(timeNow.minutes/60))*30
			minHand.x=200,minHand.y=100;
			minHand.rotation=timeNow.minutes*6;
			clockUp.addChild(cFace);
			clockUp.addChild(hrHand);
			clockUp.addChild(minHand);
			return clockUp;
		}
 
		public override function doAlarm():void
		{
			alarm.alarmPlay();
		}
 
		public override function offAlarm():void
		{
			alarm.alarmOff();
		}
	}
}

The clock radio implementation uses a Sprite backdrop from the Library. The “digital” output is a text field with the current time (in hours and minutes). It is set up in a 12-hour loop even though no “AM” and “PM” indicators are used. (Think of it as another opportunity for improvement.) The important feature is that it uses the same interface (abstract class parent) and instantiates the concrete alarm just like the analog clock.

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

//Clock radio implementation of IAlarmClock
package
{
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
	import flash.text.TextFormat;
	import flash.display.Sprite;
	import fl.motion.AdjustColor;
 
	public class RadioClock extends IAlarmClock
	{
		private var clockUp:Sprite=new Sprite();
		private var clockRadio:RadioFace=new RadioFace();
		private var timeField:TextField=new TextField();
		private var timeFormat:TextFormat=new TextFormat();
		private var hr:String;
		private var mn:String;
		private var fullTime:String;
		private var adjust:uint;
 
		public override function curTime():Sprite
		{
			alarm=new RideAlarm();
			timeNow.hours>12 ? adjust=timeNow.hours-12:adjust=timeNow.hours;
			hr=String(adjust);
			mn=String(timeNow.minutes);
			mn.length==1 ? mn="0"+ mn : mn=mn;
			fullTime=hr+":"+mn;
			timeField.autoSize=TextFieldAutoSize.RIGHT;
			timeFormat.font="OCR A Std";
			timeFormat.color=0x00ff00;
			timeFormat.size=72;
			timeField.defaultTextFormat=timeFormat;
			timeField.text=fullTime;
			timeField.x=95,timeField.y=75;
			clockUp.addChild(clockRadio);
			clockUp.addChild(timeField);
			return clockUp;
		}
 
		public override function doAlarm():void
		{
			alarm.alarmPlay();
		}
 
		public override function offAlarm():void
		{
			alarm.alarmOff();
		}
	}
}

As you can see from the code, it’s very flexible but forms a strong orthogonal component. Changing an alarm requires only that the name of the MP3 file is changed. A quick cut-and-paste and you have another alarm sound or tune. Changing clocks requires a new clock face, but adding another can easily fit in with the other interacting participants in the pattern, and that’s what is important.

Making Requests through the Client

The Bridge includes the Client as an implicit class participant in the pattern. In this example, the Client is more like a sales associate who’s job it is to display the wares—the clocks and their alarms. Most of the code in the Client is creating the buttons and event handler methods. The methods include a good number conditional statements that check to see if the an extant instance of the clock. In testing, I found that the program would crash faster than a drunk driver if the current usage of an object were not first checked. In a non-demonstrative application, all the client would do would be to instantiated the selected clock and let it take care of the alarm event.

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

//Client
package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var aClock:IAlarmClock;
		private var selectBell:Button=new Button();
		private var selectRadio:Button=new Button();
		private var testAlarm:Button=new Button();
		private var shutOff:Button=new Button();
		private var clockNow:Sprite=new Sprite();
		private var btnWidth:uint=shutOff.width+10;
 
		public function Client()
		{
			addChild(clockNow);
			selectBell.label="Analog Clock";
			selectBell.y=250,selectBell.x=10;
			selectBell.addEventListener(MouseEvent.CLICK,getBell);
			addChild(selectBell);
 
			selectRadio.label="Radio Clock";
			selectRadio.y=250,selectRadio.x=btnWidth+10;
			selectRadio.addEventListener(MouseEvent.CLICK,getRadio);
			addChild(selectRadio);
 
			testAlarm.label="Test Alarm";
			testAlarm.y=250,testAlarm.x=2*btnWidth+10;
			testAlarm.addEventListener(MouseEvent.CLICK,alarmTest);
			addChild(testAlarm);
 
			shutOff.label="Turn Off Alarm!";
			shutOff.y=250,shutOff.x=3*btnWidth+10;
			shutOff.addEventListener(MouseEvent.CLICK,offNow);
			addChild(shutOff);
		}
 
		private function getClock()
		{
			removeChild(clockNow);
			clockNow=aClock.curTime();
			clockNow.x=20,clockNow.y=10;
			addChild(clockNow);
		}
 
		private function getRadio(e:MouseEvent)
		{
			if (aClock)
			{
				aClock.offAlarm();
			}
			aClock=new RadioClock();
			getClock();
		}
 
		private function getBell(e:MouseEvent)
		{
			if (aClock)
			{
				aClock.offAlarm();
			}
			aClock=new BellClock();
			getClock();
		}
 
		private function alarmTest(e:MouseEvent)
		{
			if (aClock)
			{
				aClock.doAlarm();
			}
		}
 
		private function offNow(e:MouseEvent)
		{
			if (aClock)
			{
				aClock.offAlarm();
			}
		}
	}
}

As noted, the clocks and their alarms are set up in what might be called “frozen” demo mode. In fact, the Client just uses an IAlarmClock implementation and its methods to select a clock and turn the alarm on and off.

We always welcome your comments, and we hope to hear from you about this pattern. Also, we’re really hoping that you send in some components that you have created that we can put into this app. In the next post, you’ll be treated to a discussion (rant?) about using parameters in applications like this one. (Duck!)

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.