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

I’ve got nothing against 4th Graders.

It was in relation to the MVC, which is the precursor to the Gang of Four’s catalog of patterns, but it’s appropriate in this discussion as well. Originally, I was asked what I had against MVC, and I said, Nothing, and I’ve got nothing against 4th graders either. The reference was to getting stuck in the MVC in a continuous loop—just like getting stuck in the 4th grade. The MVC is brilliant because it helped free programmers from monolithic conceptualizations in programming. However, it’s a starting point; not an ending point. The Pure MVC advocates certainly agree with that idea, and that’s fine, but pure or (impure?) MVC, it’s still an MVC. The GoF make the point that different patterns can be developed around what varies in an application, and the MVC is a way to deal with UIs and has much in common with the Observer pattern; which leaves some 20 other patterns that focus on different variations. (Later developments of the MVC have elevated it to an architecture.)

In my own case, I got stuck on the State pattern for about a year and decided that it was time to move on after realizing that other patterns would serve me better when something other than state varies. Redoing my Web site now, I wish I had used design patterns in more than the video player I made with a State pattern.

Why OOP? What’s Wrong with Sequential Programming?

First off, let’s get straight what we mean by sequential programming. In one context, it means Not Parallel Programming or Not Concurrent Programming. Just ask anyone at Intel. They think that everyone should learn concurrent programming based on the fact that their processors are all multi-core, and single core processors have gone the way of the Dodo bird. They’ve got a point. In looking at my collection of computers my old Win XT may be single core, but I’m not even sure that’s it’s not a dual core. My Macs and Win 7 (64-bit) systems are all dual or quad core. (See Joe Duffy’s book, Concurrent Programming on Windows for about 1,000 pages of info on this kind of programming.) Just to be straight about the point, that’s not the kind of sequential programming I’m talking about.

In this post, I’m referring to non-structured programming where you just write one line after another. When I used to write assembly language programs (especially using the assembler I wrote myself) everything was non-structured. Likewise, a lot of the Basic programming I wrote was sequential along with Fortran and non-Pascal stuff. If I had to put a date on it, I’d guess such programming is about 60-70 years old. It’s not old school; it’s just old.

What’s wrong with sequential programming? Is it slower? Does it not execute correctly? Are there algorithms I cannot write with it?

No to all of the above.

It’s main shortcomings center around the spaghetti factor. After not too many lines of code, it’s easy to get tangled up. If your programs are short, you’ve got little to worry about with good ole’ sequential programming. Otherwise, sequential programming is difficult (near impossible) to maintain, change and keep straight.

However, you’d be amazed by the number of programming books that still present coding in nothing but sequential structure—which is non-structured. (In the past I’ve been guilty of the same thing; so I’ll be throwing no stones.) Some authors who have attempted to do otherwise have been snarled at…What about the beginners? What about the non-developers?! Grrrr! So it’s not just complacent code-writers who create programs in nothing but sequential structures; some authors do the same.

To be fair, a lot of the code in computer books is presented in snippets—little bits of sequential code to explain the syntax or to provide a working example. That’s fine and not what I’m talking about. In good books all of the bigger examples are in OOP or at least procedural programming. What I’m talking about are books where everything in the book is presented as sequential programming. One I have in mind showed a three-tiered if statement that was part of a bigger sequential monstrosity. How that mess helps beginners is beyond me. (By the way, the particular book I have in mind was published in 2009 by one of the most reputable computer book publishers in one of the most respected series.)

Oddly I found that by working with design patterns I end up doing simple sequential snippets—none of the messy spaghetti stuff. Read on to see why.

Procedural Programming to the Rescue!

If I had to summarize procedural programming in one word, it would be functions. If I see the keyword “function” in a program, I can assume that the programmer is at least using procedural programming. The great thing about procedural programming is that you can re-use the same function all you want and it’s a whole lot easier to organize a task.

The problem that comes up in procedural programming centers around scope. Global variables can be used with many different procedures (functions), but they are more likely to creep in where they’re unwanted and screw up a program. Local variables are tethered to functions, and you may have occasion to use one of their values, but since they’re scoped to the function, they have a whole other set of issues. So while a huge improvement over sequential programming, programmers still had many challenges to face with procedural programming.

OOP Emerges: Encapsulation

Like Procedural Programming that can be summarized by the use of functions, Object Oriented Programming (OOP) can be summarized by encapsulation. To prevent the scoping problems and aid in debugging, the concept of the object emerged as a fully contained set of properties (something like variables) and methods (encapsulated functions). The objects were built in classes and a set of rules regulated communication between objects using accessors—private, protected and public. Classes represent abstractions of different entities that can be used to get something done in a program. The key to getting something done is through communication between the objects and implementing concrete instances of abstract classes. That’s an oversimplification, but clearly the focus shifts from sequences to communication.

Design Patterns: Organized but Loose

While OOP went a long way to create a programming model that could handle larger programs, some of the communication between objects resulted in a kind of binding that made re-use and change very difficult. In fact, some large and complex programs requiring even a little change had to be re-built from the ground up.

In 1979 the Model View Controller (MVC) offered a way to build interfaces for SmallTalk using the MVC triad of classes. It was key in de-coupling classes that had previously been grouped together.

In 1995, Gamma, Helm, Johnson and Vlissides came out with a catalog of 23 design patterns organized around the purpose of the pattern (Creational, Structural and Behavioral) and the pattern scope (Class or Object). They offered six different criterion for selecting a pattern, key among them examining what you want to vary to avoid redesign and encapsulate what varies.

Professional programmers, in both industrial and higher educational settings, adopted or professed the use of design patterns. The purpose then as now is to aid in the development of software that is characterized by change and revision. In some respects they are OOP solutions to common programming structures. They are not templates as design templates in graphic design are. Rather they are broad yet precise ways to organize classes around frameworks with a general and common programming goal.

Do Design Patterns Add to or Reduce Complexity?

For some, all that design patterns accomplish is to create a more complex system for both thinking about programming and creating a program. True, they do take some time to fully grasp, but so does programming. However, design patterns provide a fairly complete set of structures for dealing with programming problems. Further, once adopted, they save a great deal of time in re-structuring and making program changes.

Oddly, using design patterns, I find myself back writing simple sequential code. Consider the fact that classes should only take on a single responsibility and are organized around an abstract interface. I know the required signatures for the method, and I know the classes and their relationship to other classes. So what’s left for me to do? I just write snippets for the methods—little sequences of code that are fired when the method is called. Because objects are organized around a known communication system (a framework), I don’t have to worry about how they get along with the other objects. All of my requests are from a Client class, and the requests are nothing more than little sequences that instantiate a class and use the object’s methods and properties.

Now, I go back and look at the “easy” and “fun” book that has nothing but sequential programming (the word “function” is not even in the Index). I see a river of nested conditional statements in loops. That’s easy? Revision? Forget about it! I’m happy writing my little snippets inside well organized methods inside classes that I can easily re-use and revise.

What good are interfaces?

Design Patterns were founded in the context of OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) gatherings sponsored by the ACM (Association for Computing Machinery) and attended by both academic and industry programmers. These are smart folks in the world of computing, but as I’ve mentioned on other occasions, they are far less arrogant and more willing to listen to others—especially if those others listen to them in turn. Everyone assumes that everyone else is knowledgable and if they have a question, they get a straight answer–not a I’m smarter than you answer, but an-answer-to-the-question-asked kind of answer. I appreciate that because I’ve got a lot of questions.

At the last OOPSLA meeting (now called SPLASH), I got into an argument with a programmer and we both got our backs up. However, we both realized that the other was sincere, and we both shared the common goal of learning more about the topic; and the result was that she and I learned from one another. Mostly, I just ask straight questions and get straight answers—or give them. Sometimes mine or others answers may clash, but that’s what happens when you share ideas.

Now to the point. The other day I was snooping around the internet for a good distinction between abstract classes and interfaces and I came across a link to a blog that promised such a distinction. In discussing the distinction, the blog’s host first went on a long-winded detour to tell us how smart he was and how he used a “test question” to queries about programming. The “test question” was to distinguish between abstract classes and interfaces. His “answer” was hopelessly vague and muddled. What a jerk!

So, I am going to try and come up with a clear idea of what a class interface is and why we should care about it. I’ve included an interface example further on in the post, but you can download the files here:

Straight Answer to “What is an Interface?”

In our book on page 19, the section, The many meanings of interface, differentiates between user interfaces and object interfaces and notes that the ActionScript 3.0 keyword interface that is used to declare an interface structure is yet still another type of interface. Essentially, an interface is an abstract structure with a list of unimplemented methods whose signatures must be used in any implementation of the interface. That’s about as clear as mud in terms of what an interface is used for. It’s a straight enough answer, but clarifies nothing, nada, nichts, rien, niente.

In attempting to arrive at a good answer I looked at the Adobe documentation, and while I found nothing inaccurate and lots of examples I found nothing clarifying. So, I decided to back up and look at the more general concept of interface. One that we all seem to know and understand is that of a user interface. An interface that allows users to communicate with a computer program is a user interface. A simple example is a button. If I click a button, I can interact with the program—it is the interface. Click the button below to see what I mean:

Essentially, you were able to “touch” the program to make it do something. Okay, so we know a user interface is between the user and the computer’s program. Likewise, a TV set is an interface between a user and television programming across the airwaves, via satellite or from cable.

With that in mind, an ActionScript 3.0 interface must be between something and something. Further, there must be a good reason for having such a relationship. So, with this in mind, I went back to the hunt. What I found was surprisingly simple and yet very clear.

An Abstraction of Service

About five years ago, O’Reilly published a book entitled Programming .NET Components by Juval Lowy. In it Lowy discusses, among other things, the purpose of using interfaces. He uses a model of what he calls component-oriented programming (COP), and while there may be some differences between OOP and COP, they share certain basic assumptions about loose coupling. He calls interfaces, an abstraction of service, in the sense that a service is part of your program that does something—usually found in the class methods. In a nicely worded summary, he notes,

When you separate the interface from the implementation in your programming, your client is compatible with far more services.

While not putting it in those words, Chandima and I have been making the same point both on this blog and in our book. Again and again we’ve discussed how a Client class is the one that makes requests. However, what does the Client make the request for? Why services, of course. Because the interface can only state the methods’ signature (see page 19 of our book for a good diagram and explanation of a signature), it can be implemented in many different ways. Thus, a client can create an instance that will make requests through the interface that provides both variety and the ability for the programmer to make later changes without changing the Client.

It’s All About Communication

OOP is all about communication between objects. Just like the button is a human interface for communication between the user and the service (in the program), an interface is for communication between Client and Implementation or between Class and Class or Object and Object. The following example uses an interface through which the client requests services—one to make an ellipse and the other to make a triangle.(You can download them using the download button at the top of the post.) Click the (patent pending) Acme Interface Button again:

To get started the Client class is the first in the listings here because it best illustrates how the Client requests the services through the interface, (IGraphic).

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

package
{
	import flash.display.Sprite;
	import flash.display.Shape;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class GraphicClient extends Sprite
	{
		private var requesterE:IGraphic=new EllipseGraphic();
		private var requesterT:IGraphic=new TriangleGraphic();
		private var triBtn:Button=new Button();
		private var ellipseBtn:Button=new Button();
		private var holder:Sprite=new Sprite();
		private var flexShape:Shape=new Shape();
 
		public function GraphicClient()
		{
			setButtons();
			holder.x=0,holder.y=55;
			addChild(holder);
			holder.addChild(flexShape);
		}
 
		private function triService(e:MouseEvent):void
		{
			holder.removeChild(flexShape);
			flexShape=requesterT.doDraw();
			holder.addChild(flexShape);
		}
 
		private function ellipseService(e:MouseEvent):void
		{
			holder.removeChild(flexShape);
			flexShape=requesterE.doDraw();
			holder.addChild(flexShape);
		}
 
		private function setButtons():void
		{
			triBtn.x=100,triBtn.y=100;
			triBtn.addEventListener(MouseEvent.CLICK, triService);
			triBtn.label="Request Triangle";
			addChild(triBtn);
 
			ellipseBtn.x=100,ellipseBtn.y=130;
			ellipseBtn.addEventListener(MouseEvent.CLICK, ellipseService);
			ellipseBtn.label="Request Ellipse";
			addChild(ellipseBtn);
		}
	}
}

Originally, I used a single request instance typed to the IGraphic interface, but each time it was called I had to instantiate a new concrete triangle or ellipse class. That was done to illustrate the flexibility of programming to the interface. However, even an illustration isn’t worth the bad practice of continually using the new statement each time one of the button clicks requests a triangle or ellipse. So, I created two IGraphic types, one for a triangle request and the other for an ellipse request. In this way only a single new statement was used for each object and the new statement is required only once for each object no matter how many times it is used.

The rest of the program is pretty simple. Two classes implement the IGraphic interface and provide public access to call the doDraw() method.

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

//Interface
package
{
	import flash.display.Shape;
 
	public interface IGraphic
	{
		function doDraw():Shape;
	}
}
 
//Triangle
package
{
	import flash.display.Shape;
 
	public class TriangleGraphic implements IGraphic
	{
		private var standardTriangle=new Shape();
 
		public function doDraw():Shape
		{
			standardTriangle.graphics.beginFill(0xcc0000);
			standardTriangle.graphics.drawTriangles(Vector.<number>([ 100,100,  200,200,  100,200]));
			standardTriangle.graphics.endFill();
			return standardTriangle;
		}
	}
}
 
//Ellipse
package
{
	import flash.display.Shape;
 
	public class EllipseGraphic implements IGraphic
	{
		private var standardEllipse=new Shape();
 
		public function doDraw():Shape
		{
			standardEllipse.graphics.beginFill(0x00cc00);
			standardEllipse.graphics.lineStyle(3,0x0000cc);
			standardEllipse.graphics.drawEllipse(100, 100, 100, 100);
			standardEllipse.graphics.endFill();
			return standardEllipse;
		}
	}
}

The purpose of this example is to show how the interface provides a simple and clear gateway for the client to access services. As the program grows and changes, it is also quite simple to update other services through the same interface.

OOP Interfaces

One of the ironies I discovered in creating this example was found in the Gang of Four’s discussion of an Object interface (not a framework or program interface). An object’s interface is the set of all signatures defined by an object’s operations. They note,

An object’s interface characterizes the complete set of requests that can be sent to the object. Any request that matches a signature in the object’s interface may be sent to the object. pg. 13

Where a program’s interface (such as the IGraphic one used in the example) is interacting and communicating with objects whose own interfaces are synched, you can imagine both a well-oiled machine through which the different parts communicate as well as one where change and additions can be added seamlessly. So the question may not be, What are interfaces good for?, but instead, How’d I get along with out them for so long?

Constructor Function Attacks Design Pattern

Obviously you don’t ever remove a constructor function from a class—one will be generated automatically if none is there. Instead, if you do not include one, you’re not tempted to add properties and methods in the constructor that might generate dependencies that you don’t want. Your client isn’t a problem because it’s just making requests and none of the other classes instantiate your client. However, every participant in a design pattern that has a constructor function is liable to generate unwanted dependencies because it automatically passes everything in the constructor function to the instance. That’s why it’s like a cluster bomb—everything is liable to be a target not distinguishing friend from foe—the foe being unwanted dependencies that jam up your program when you make revisions. This includes “parameterized” classes. Instead of passing a parameter to the class, it’s less binding to pass it just to the method that uses it. If everything in a class is needed immediately by the constructed instance, it’s not exactly difficult to first instantiate an instance and then call a method through the instance that fires off the whole crew.

As far as rants go, this one is pretty mild. So try programming your classes without a class constructor and see if it isn’t easier to both debug and update. I’ll be sure to do the same in future design patterns I post here.

Creates Relationship

• Abstract Factory
• Builder
• Factory Method
• Command
• Memento

This post examines how design patterns incorporating a creates relationship uses that relationship to make a loosely structured design to complete one or more kinds of tasks.

Uses of Creates

In virtually any OOP programming, some sort of creates relationship exists; sometimes no more than a Client instantiating an instance of a class. However, when dealing with design patterns, we are looking for a specific purpose in terms of the overall design for the use of a creates relationship. For example, in the Memento pattern, the Originator instantiates a Memento object with the following code:

1
2
3
4
5

public function createMemento ():Memento
{
       trace ("Creating memento with current state");
       return new Memento(mstate);
}

In the Memento pattern, the Memento class has an aggregate relationship with the Caretaker participant which stores the current state in an array (in our example.) In looking closely at the relationship between the Originator and the Memento, when the Originator instantiates an instance of the Memento, it is really acting as a setter—it sets a specified state as the memento, which in turn is stored by the Caretaker when called upon. Effectively, the process decouples the Originator from the Caretaker.

Factory Work

In thinking of the create relationship, one of the Factory designs most likely comes to mind. Not surprisingly, both the Abstract Factory and Factory Method include a create relationship. The Concrete Creator class has a create relationship with the Product class. The whole concept of a factory is one where something is created, and that’s exactly where we’d expect to find a create relationship.

One apparent exception is the Flyweight Design Pattern. No create relationship is seen in the Class Diagram, but in looking at the Factory participant in the design, you will find that elements in an associative array are made up of instantiated ConcreteFlyweight instances. (Associative arrays in ActionScript 3.0 are created as Objects and the elements are the Object properties.) The more complex multiple aggregation masks the create relationship.

The Uses-A Relationship

Of all of the ways to describe what happens with the dashed line and arrow, I prefer the uses-a description. This is consistent with has-a (composition) and is-a (inheritance) relationships. It’s easy to say that Participant A uses a Participant B object through instantiation. GoF simply call it the creates relationship (p. 364), and let it go at that. Scott Myers in his book Effective C++ uses the term is-implemented-in-terms-of to reference such a relationship. Myers points out, IS-IMPLEMENTED-IN-TERMS-OF is a relationship between classes that exists in the implementation domain. The implementation domain is contrasted with the application domain where you have has-a relationships (composition.)

In any event, this concludes our series on relationships between design pattern participants. We hope it helps you better understand what all of the symbols mean, and while the lines of demarcation between types of relationships may become blurred, at least you have the basics so that you can better understand a design pattern’s class diagram and what’s going on in a pattern. Start looking at your own code in terms of these relationships, and Who knows?, maybe you’ll discover you’ve been using one that you didn’t realize before.

Your valuable comments are welcomed as always, along with questions, insights and examples.

Inheritance Relations

• Singleton
• Facade
• Memento

So when thinking about inheritance, you can begin by thinking design patterns because most include some kind of inheritance in the relations between pattern participants.

But I thought they said…

You’re probably thinking that a key principle for design patterns is to favor object composition over class inheritance, and here we find that the Gang of Four is using inheritance in all but three of their design patterns. What’s up with that?

With a single exception, all of the inheritance in the design patterns is from an abstract class or interface. The exception can be found in the Adapter pattern, where the Adapter participant inherits from both an abstract participant (Target) and a concrete one (Adaptee). What an inheriting class is getting, then, is an interface, whether in the form of an implemented interface participant or extended from an abstract class participant.

The first principle of Design Patterns is

Program to an interface, not an implementation.

Following that first dictum is the one to favor object composition over class inheritance. However, to program to an interface, you need an interface or abstract class. Therefore, even though composition is favored over class inheritance, the patterns are set up with composition through an interface—which is perfectly clear in the vast majority of the design patterns. The following statement by Gamma, Helm, Johnson, and Vlissdes now makes perfect sense:

Reuse by inheritance makes it easier to make new components that can be composed with old ones. Inheritance and object composition thus work together.

The concrete classes that can be composed are done so through their interface. That’s why the diagrams show the composition arrows aiming at the interfaces and not the concrete classes. However, though those interfaces the requests can be handled by the concrete classes, but addressing them through the interfaces keeps the relations looser. Then, when change occurs, the change does not lock up and crash the program because the program is tied into concrete implementations.

All those Concrete Classes can be Composed

If we think of the concrete classes (child classes) that implement an interface or abstract class as to be composed we can better see the relationship between inheritance and composition. Because several concrete classes may share the same or similar interface it makes far more sense to create them through an interface than using identical interfaces with several separate classes. In this way, you can begin to understand the child classes as building blocks for composition and not some unrelated classes that happen to be handy for composition. Were the latter the case, it would not be important to program to an interface rather than an implementation.

Inheritance and Composition Getting Along Fine

To see a simple yet effective example of both inheritance and composition working together, take a look at the Strategy pattern. In that pattern, the Context class forwards requests from the Client to the Strategy interface. The Context class does not request anything concrete. Rather, it simply requests something from the Strategy participant, the specifics of which are provided by the Client’s request in the form of a parameter. In this particular example, it wants something to load graphics. Suppose, you change it so that you want it to load text as well. No need to change the Context because it is making request through the Strategy interface (an abstract class). By subclassing the abstract Strategy class (ILoadMaster in the example), you can add a different implementation to load text. Then, compose a different request in the Client, and viola!, you can now load text without the whole thing crashing around your shoulders or having to do a lot more work.

Overuse of Inheritance is the Problem

The only real problem that the Gang of Four have with inheritance is its overuse. As you can see composition works in conjunction with inheritance in all but three design patterns. So don’t get the wrong idea about design patterns and inheritance—there’s nothing anti-inheritance about them. The problem lies where inheritance is used to the point where a program is locked into concrete implementations without programming through the interface. In fact, an interface implies some kind of inheritance. By working with composition and inheritance together, you can have the advantages of reuse through inheritance and new objects composed of concrete objects. Truly this is the best of both worlds.

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.

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.

Before examining why instantiating instances using new is not a good thing, let me explain where I got the idea. It came from the GoF (indirectly) and the Freemans’ Head First Design Patterns (directly). This is not to say that both acquaintance and aggregation type relationships cannot hold a reference to another class by instantiating an instance of the other class. (The Proxy example on this blog does that.) Likewise, it may be impossible to do serious development without using at least some new statements and so the title indeed contains a bit of hyperbole.

The key idea behind design patterns is that you want your programs to be as flexible as possible. The dictum, program to an interface, not an implementation is an invitation to more flexible designs. When you create an instance using new in effect you lock into using the specific implementation. The more new statements in a program, the more tied up it is in whatever implementation you’ve elected to instantiate.

At the same time, I wanted to go over the different class relationships to connect the conceptual with the actual. When I look at a class diagram and see different relationships between classes, often I feel queasy about the relationships independent of a specific example. This is especially true with non-ActionScript 3.0 examples where the application invokes some built-in feature of the alien language. Suddenly, the example is sucked into a black hole remaining a mystery for ActionScript developers. We’ll avoid that here.

Inheritance Is-A First Step

We are advised by the Gang of Four to favor composition over inheritance, but inheritance is a fundamental part of most design patterns, so it’s a good place to start. It’s also the easiest place to show where you can invoke a method without using new, We’ll begin with the symbol in the class diagram in Figure 1.

Figure 1: Inheritance relationship

As you can see in Figure 1, the relationship between the Parent class and Child class is pretty simple and straightforward. The Child inherits all of the Parent characteristics. As a result, the Child has a strong and tight relationship with the Parent with little flexibility. Now let’s implement that without using the new statement in a program that invokes the Child.

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

//Parent Class
package
{
	import flash.display.Sprite;
 
	public class Parent extends Sprite
	{
		public function Parent()
		{
			 //constructor
		}
 
		public function parentMethod():void
		{
			trace("Is-a is using me, the Parent");
		}
	}
}
 
//Child Class
package
{
	public class Child extends Parent
	{
		public function Child()
		{
			this.parentMethod();
			childsPlay();
		}
 
		private function childsPlay():void
		{
			trace("This is a child original.");
			trace("Mouse location: "+ mouseX);
		}
	}
}

When you test this application (calling the Child) in either Flash or Flex, you’ll get the following output:

Is-a is using me, the Parent
This is a child original.
Mouse location: 147


I might add that the Parent class inherits the built-in Sprite class, and so the Child class inherits all of the Sprite class properties as well. To illustrate this, the mouseX property is inherited from the Sprite class. In turn, Sprite inherits mouseX from the DisplayObject class. So the Child class method is able to use the mouseX just as it would with any other class that inherits from a class that extends the Sprite class.

You may be thinking that inheritance is used in virtually every design pattern in our book and on this blog (not to mention the GoF book), and so what’s wrong with inheritance? Besides, inheritance is an essential part of OOP. In looking at the design patterns, the little triangle indicating inheritance is typically done so with an abstract class or interface. Where you see the key words extends or implements in a program, you will see the inheritance triangle. However, what you may not see is the fact that the parent class is either an interface or abstract class. Only the fact that the class name is italicized lets the developer know that the parent class is abstract, and a quick glance often misses that essential point. Inheritance from an abstract class or interface provides a looser coupling in that the subclass has a good deal of flexibility (think polymorphism) as to what the implementation will actually look like.

The further one moves down the structure from the origin class or classes to concrete subclasses, the more tightly bound subclasses become to the parent class. However, as you can see simply by looking at the ActionScript 3.0 reference documentation, which nicely maps the structure of the classes, a lot of inheritance is used to make up ActionScript 3.0. For example, the ActionScript 3.0 TextField class has a fairly long inheritance trail:

TextField -> InteractiveObject -> DisplayObject -> EventDispatcher -> Object

Subclasses from the TextField class would further tighten up the connections and possible inherited baggage. So while inheritance is fundamental to good OOP, where possible, GoF recommends other class relationships.

Acquaintance

When two classes are connected through acquaintance one class has a relationship to another class in the form of a pointer, reference or, less commonly, an instance. A solid black line with an arrowhead and optional reference name in a class diagram indicate that the class on the back of the arrow, uses the class it points to. Figure 2 shows a uses-a relation diagram:

Figure 2: Acquaintance

A recent example in this blog of an acquaintance can be found in the Proxy design pattern. The Proxy class holds a reference to the Real Subject. In the example the ProxyLogin class holds a reference to a RealLogin class as seen in this following code snippet:

1
2
3
4
5
6
7
8

public function login():void
{
     if (loggedIn==null)
     {
          loggedIn=new RealLogin(username);
     }
     loggedIn.login();
}

That certainly keeps a reference to RealLogin(), but it’s not the best example of keeping a reference to another class. It instantiates an object of the class inside a conditional statement, and that’s a fairly weak kind of delegation. It instantiates an object when needed, and in that sense uses the other class. However, both the RealLogin and ProxyLogin implement theISecurity interface; so they already have a connection. Acquaintances are supposed to be loose, but they’re also supposed to associate one class with another—not just instantiate an instance of the class. Let’s look at a better example of acquaintance in the Observer pattern.

The relationship between the Subject interface and the Observer interface is a very nice example of class acquaintance. (See Chapter 8 ActionScript 3.0 Design Patterns for the full discussion of the Observer pattern.) The Subject interface has an acquaintance with the Observer interface. It does so in the parameter of the Subject’s methods:

1
2
3
4
5
6

public interface Subject
{
	function subscribeObserver(o:Observer):void;
	function unsubscribeObserver(o:Observer):void;
	function notifyObserver(o:Observer):void;
}

That’s pretty simple, but it better shows a nice loose kind of relationship. On the Observer side, the interface is,

1
2
3
4

public interface Observer
{
      function update();
}

That really doesn’t tell you a lot, but it provides an idea of what might be considered an acquaintance. Essentially, holding a reference of some sort sets up a loose coupling. However, we need to look at aggregation to better understand acquaintance.

Delegation through Aggregation

I’m attracted to aggregation like a fly to a spider web—often meeting a similar fate as the fly. I’m easily entangled. Let’s start with the formal outline of aggregation. Again, you will see an arrow pointing to the aggregatee, but on the aggregator’s end is a diamond.

Figure 3: Aggregation

If you look carefully at Figures 2 and 3, they’re difficult to tell apart. Both types of relationships hold references to other classes. Usually, the two are differentiated by pointing out that aggregation is a stronger relationship than acquaintance and that the lives of the classes are intertwined in aggregation more so than with acquaintance. That’s true, but Gamma, et al note that differentiating one from the other is more a matter of intent than design. Both acquaintances and aggregations are typically included as pointers and references but less commonly they can be included as instances (as we saw with the Proxy example.) However, both relations are types of composition that go into creating a design pattern, and they do so using composition rather than inheritance.

The aggregation relationship is where the aggregator (Class A in Figure 3) has-a aggregatee (Class B in Figure 3). By my count 10 of the 23 design patterns use aggregation and 12 use acquaintance. (3 use both). Almost all of the design patterns use inheritance, but most inheritance is from an interface or abstract class.

Hang Loose

So loose coupling between classes is the key to all relationships and instead of worrying about aggregation, acquaintance and inheritance (and splitting hairs over their differences), the focus should be on loose coupling. The Template Method is one of the few design patterns that has neither acquaintance nor aggregation. However, it is wonderfully loose because its key algorithm is abstract but ordered. The operations that make up the key algorithm can provide details or be wholly abstract, leaving the details up to the concrete subclasses.

All of this discussion is the result of favoring composition over inheritance and keeping the use of the new statement to a minimum. To repeat, this does not mean that new cannot be employed either in an implementation (such as the State design pattern) or as a reference, as we noted in the Proxy. However, it was impossible to pass up a title like, No New is Good New so, while some of this discussion did touch upon the point so forcefully made by the Freemans, the message is really,

Hang loose, Dude