ActionScript 3.0 Design Patterns

Update Bridge and Participants

When we think of update and change, typically we think of adding new implementations to existing structures. However, what about tweaking a pattern? If you want to reuse a general pattern (like the Bridge we’ve been discussing), what are the “rules” about changing the pattern?

Generally, the purpose of using design patterns is so that you can make changes without disrupting the current objects. That is, you can add a new object in the form of an implemented interface or abstract class without having to worry about existing objects being disrupted or crashing the system. The bigger the project, the more important this is.

How about making a new pattern based on a few adjustments to one of the pattern participants? If you want to re-use the pattern with just a few changes, and you don’t care about the current participants, you can make small changes with big results.

The Movie Clip and Cuckoo Clock

After implementing the alarm clocks, made up of a bridge aggregated instance consisting of an AlarmClock abstract class and an Alarm interface, I considered adding a cuckoo clock to the mix. Instead of just adding a sound, I wanted to have an animated bird pop out of a door making a cuckoo sound and a swinging pendulum along . Figure 1 shows what I wanted to do with my bridge pattern.(Click the Play button to see the results. If you find it easier to follow along with the code in hand, the download button now provides both Flash and Flex compatible files.)

Figure 1: Could a Cuckoo Clock be implemented in a Bridge Design Pattern?

What’s Changed?

The cuckoo clock would have to have some kind of mechanism to have an opening door and a bird pop out. Further, when the cuckoo bird jumps out, he’ll need a “cuckoo” sound coordinated with the opening door. To make life easy, I decided to throw a cuckoo sound, bird and sliding doors into a MovieClip object and stack it on top of the clock. I re-used the BellClock implementation’s of IAlarmClock for the hands on an analog clock. However, I needed to address the MovieClip through the IAlarm implementation. To do that, I had to include a MovieClip parameter in the existing Bridge design. So, I changed the IAlarm interface to the following:

1
2
3
4
5
6
7
8
9
10

package
{
	import flash.display.MovieClip;
 
	public interface IAlarm
	{
		function alarmPlay(mc:MovieClip);
		function alarmOff(mc:MovieClip);
	}
}

Then in the implementation, I can use the MovieClip with the opening door, cuckoo bird and sound. The implementation looks different from the alarm clock bridge because it does not load an MP3 and it does trigger a play or stop play method in the MovieClip. However, there is no code on the Timeline! It’s all in the implementation of the IAlarm:

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

package
{
	import flash.display.MovieClip;
 
	public class CuckooAlarm implements IAlarm
	{
		private var goCuckoo:MovieClip;
 
		public function alarmPlay(mc:MovieClip)
		{
			goCuckoo=mc;
			goCuckoo.play();
		}
 
		public function alarmOff(mc:MovieClip)
		{
			goCuckoo=mc;
			goCuckoo.gotoAndStop(1);
		}
	}
}

As you can see, the Bridge pattern is altered very little. The IAlarmClock is the same but the implementation is able to reference the MovieClip through the IAlarm now. The following shows the cuckoo clock’s implementation of 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
28
29
30
31
32
33
34
35
36
37
38
39
40
41

package
{
	import flash.display.Sprite;
	import flash.display.MovieClip;
 
	public class CuckooClock extends IAlarmClock
	{
		private var minHand:Sprite=new CuckooMin();
		private var hrHand:Sprite=new CuckooHr();
		private var cFace:MovieClip=new CuckooHouse();
		private var alarmDoor:MovieClip=new CuckooDoors();
		private var clockUp:Sprite=new Sprite();
 
		public override function curTime():Sprite
		{
			alarm=new CuckooAlarm();
			cFace.x=100;
			hrHand.x=208.5,hrHand.y=172;
	        hrHand.rotation=(timeNow.hours+(timeNow.minutes/60))*30;
			minHand.x=208.5,minHand.y=172;
			minHand.rotation=timeNow.minutes*6;
			alarmDoor.x=100,alarmDoor.y=1;
			alarmDoor.stop();
			clockUp.addChild(cFace);
			clockUp.addChild(alarmDoor);
			clockUp.addChild(hrHand);
			clockUp.addChild(minHand);
			return clockUp;
		}
 
		public override function doAlarm():void
		{
			alarm.alarmPlay(alarmDoor);
		}
 
		public override function offAlarm():void
		{
			alarm.alarmOff(alarmDoor);
		}
	}
}

The clock is constructed very much like the analog clock in the original Bridge example. The only big difference is the addition of the MovieClip instance (alarmDoor). In communicating with the IAlarm (agregatee) the Bridge serves as a … well bridge… for the implemented IAlarmclock (CuckooClock) to pass the message that it wants the cuckoo to chirp or shut up.

Same Old Client

With the simple changes made, the client doesn’t realize or have to realize that anything is really changed. It makes the same kinds of requests as the original clock-building Bridge does.

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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class ClientCuckoo extends Sprite
	{
		private var aClock:IAlarmClock;
		private var selectCuckoo:Button=new Button();
		private var playCuckoo:Button=new Button();
		private var quietCuckoo:Button=new Button();
		private var clockNow:Sprite=new Sprite();
 
		public function ClientCuckoo()
		{
			addChild(clockNow);
 
			selectCuckoo.label="Cuckoo Clock";
			selectCuckoo.x=10,selectCuckoo.y=310;
			selectCuckoo.addEventListener(MouseEvent.CLICK,getCuckoo);
			addChild(selectCuckoo);
 
			playCuckoo.label="Play Cuckoo";
			playCuckoo.x=10,playCuckoo.y=340;
			playCuckoo.addEventListener(MouseEvent.CLICK,releaseCuckoo);
			addChild(playCuckoo);
 
			quietCuckoo.label="Quiet Cuckoo!";
			quietCuckoo.x=10,quietCuckoo.y=370;
			quietCuckoo.addEventListener(MouseEvent.CLICK,cageCuckoo);
			addChild(quietCuckoo);
		}
 
		private function getClock()
		{
			removeChild(clockNow);
			clockNow=aClock.curTime();
			clockNow.x=20,clockNow.y=10;
			addChild(clockNow);
		}
 
		private function getCuckoo(e:MouseEvent)
		{
			if (aClock)
			{
				aClock.offAlarm();
			}
			aClock=new CuckooClock();
			getClock();
		}
 
		private function releaseCuckoo(e:MouseEvent)
		{
			if (aClock)
			{
				aClock.doAlarm();
			}
		}
 
		private function cageCuckoo(e:MouseEvent)
		{
			if (aClock)
			{
				aClock.offAlarm();
			}
		}
	}
}

Despite the fact that I changed the method names in the client, any programmer can see that they’re the same ones used for the original alarm clock. (The changes were to bring attention to the new type of clock.)

Easy Changes

Usually when we think of changes and re-use with design patterns, the focus is on different implementations of existing abstract participants. However, design patterns can be envisioned in terms of small changes in the pattern to produce a new implementation of a pattern with minimal changes but opening up the door for a whole new kind of structure and opportunities for that structure. The Bridge pattern offers the flexibility that all design patterns have in terms of making changes without disruptions in the project. At the same time, new structures are just as easy to change for a new set of possible implementations.

The variation in the Bridge pattern is the implementation of an object. With the two alarm clocks we saw that both different implementations of the clock (analog and digital) and the alarms (bell and music).

This wraps up the saturated Bridge series, and I hope you have enough depts in the design of the pattern to use it when you need an appropriate Behavioral design. In this last installment, the purpose has been to keep in mind that changes are easy when your code is in a design pattern, but you can also make little changes in a pattern to open up a whole new set of possibilities. Remember, all kinds of changes are easy with ActionScript 3.0 using design patterns.

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.
Read more…

Independent Variation by Decoupling Abstractions and Implementations

The concept that you can decouple an abstraction from its implementation sounds flat out bizarre. Whether talking about an interface or an abstract class, how in the world is it possible to implement a concrete class that is not affected by changes in the interface? If the abstraction varies, the concrete implementation is either going to change or crash. If you use an interface, you’ll have some kind of abstract method set up that is implemented by a class using the interface and its signature. If I change the interface even minutely, something is going to change in the implementation or it will crash. Suppose I change the return type in one of the methods from a Number to a String, what’s going to happen when I run the program? It will throw an error.

For example, try the following:

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

//Client
package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var doFirst:IFace;
		public function Client()
		{
			doFirst=new Imp1();
			trace(doFirst.doThing());
		}
	}
}
 
//Interface
package
{
	public interface IFace
	{
		function doThing():Number;
	}
}
 
//First (correct) Implementation
package
{
	public class Imp1 implements IFace
	{
		public function doThing():Number
		{
			return 55;
		}
	}
}

That works just as expected. No big deal, the interface implementation is correctly formed. Now, make the following variation and try it:

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

//Modified Client to call new implementation
package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var doFirst:IFace;
		public function Client()
		{
			doFirst=new Imp2();
			trace(doFirst.doThing());
		}
	}
}
 
//Modified implementation
package
{
	public class Imp2 implements IFace
	{
		public function doThing():String
		{
			return "Hello World!";
		}
	}
}

The only thing that was changed was the return data type from Number to String. Here’s the Crash results:

Line 3 1144: Interface method doThing in namespace IFace is implemented with an incompatible signature in class Imp2.

So how can you have independent variation between an abstraction and its implementation?

The Bridge to the Moon

When thinking about an image for this series on the Bridge design pattern, I considered a number of bridge images. However, the Bridge intention is to,

Decouple an abstraction from its implementation so that the two can vary independently.

The idea of a bridge to the moon popped up because the earth and the moon have different orbits (and a few other things) but share much in common and exert an influence on one another. The idea of a bridge to the moon is one way to think about decoupling and connections at the same time. An even better way is to take a look at the Bridge class diagram in Figure 1:

Figure 1: Bridge Class Diagram

Now, when we think about decoupling an abstraction from its implementation we can see that the Gang of Four made both the abstraction and implementation abstract! The implementation in the sense that we use extend from an abstract class or implements from an interface has a whole new meaning.

When an aggregate relationship exists between two classes (or interfaces) they create something akin to a concurrent object with different implementations possible. In this case the aggregate relationship is between two interfaces (or abstract classes), and you can begin to understand independent variation. So we need to look more closely at what exactly varies.
Read more…

Bridge with a new twist

Recently, Don Cooper took a look at the pattern and came up with a slightly different twist. In Don’s own words,

Attached is my solution for the bridge pattern, based directly on your own code. I thought it made more sense in any case to keep the graphic-making code inside the implementor, and I just needed to change the return type to Shape to make it happen, along with other stuff you’ll see. I think I could also have embedded it inside a Sprite in the implementor and passed that as a return type in order to take advantage of the InteractiveObject inherited (mouse-able) functionality, if the background needed to be clickable.

You can download Don’s solution–just click the download button:

For details on the Bridge pattern, check out the original Bridge post. Enjoy!

Like most of the design patterns we’ve dealt with both in our book and on this blog we like to start with a minimalist example and then provide a more concrete and useful example. With the Bridge design pattern, the example is fairly minimalist, but it has been designed to create graphic backdrops for video objects. So, while not exactly minimalist and certainly not abstract, the Bridge example here is still fairly simple. (Well, at least as simple as design patterns ever get.) Besides, it accomplished something I needed.

Bridge Over Untroubled Waters

With most design patterns I’ve found that their abstract concepts are clearer than their actual creation. (The Mediator design pattern in this blog is a good example.) However, with the Bridge, I found that the concept was a bit muddled, but making a Bridge design pattern that actually accomplished something useful was relatively simple. To get started, take a look at the class diagram in Figure 1:

Figure 1: Bridge Class Diagram

The intent of the Bridge pattern is to decouple an abstraction from its implementation so that the two can vary independently. (GoG 151) If you don’t think about that much, it sounds like a good idea to keep an application from grinding its gears when a change is made in either the abstraction or implementation. The Freemans (Head First Design Patterns, pp. 612-613) have a great example—a universal remote control. The remote control is the abstraction and a TV set is the implementor. Concrete implementors are the different brands of TVs. As new technology arises, the remote control can be updated with new gizmos. Likewise, the TV sets can also be updated and different brands will have their own unique features. A good Bridge design will allow each to be changed without breaking the other. So far so good.
Read more…