Gentle Readers: When you click the Play button in this post, the UI that appears isn’t very pretty. That’s because I have no graphic design skills. By changing the requests in the Client class, you could easily make a much nicer UI. Why not give it a shot and send us your revised Client request set? You can even add new Concrete Creators and Products. Send in your refinements to our comment section. Either that or click Play and see Ugly!

The Concreteness of Abstraction

The first time I went to London, I picked up a Tube Map (Map of the London Underground) and was able to get where I wanted to go. The map of London’s tube is a masterpiece of clarity and abstraction. Based on electrical circuitry, it’s very easy to find one’s way around London even on a first visit. Likewise, Paris’ Metro has an almost identical type of map for it’s underground system, and it too is easy to find where you want to go. The secret is having just enough detail to use the system and not so much detail to make its use confusing. Further the coding is clear: different colors depict different named lines. Bakerloo is brown, Circle is yellow, Central is red and District is green. At a glance you see that arriving at Heathrow Airport, you take the Piccadilly line into town (purple) and switch lines wherever you see a white circle off the Piccadilly line. The details are not provided, and the Thames river does not run along the neat geometrical angles shown on the Tube Map. It’s just a reference point and lets you know whether you’re north or south of the Thames. The river’s or tube’s exact shape doesn’t matter; the whole thing is an abstraction of London’s subway system and a major feature of the city. The details would just get in the way of clarity.

Abstraction in OOP and Design Patterns works the same way. An object only exposes as much information as the client (requesting object) requires. The perfect abstract structure in a design pattern is an Interface because it is nothing but abstract methods. The only way to really appreciate abstraction is to see it in action; so this post concentrates on demonstrating abstractions in a fundamental design pattern—the Factory Method.

Two Interfaces and some Concrete Classes

The Factory Method requires a factory interface called Creator and a “product” interface called Product. The Creator interface provides a factory method function to create concrete instances of products through the abstract Product interface. In this implementation of the Factory Method Design Pattern, both abstract participants are interfaces (Creator and Product). Figure 1 shows the relationship between the participants in the design pattern:

Figure 1: Factory Method Design Pattern

In a step-through of the pattern you see the following:

1. Client wants a certain product. Makes request through the Creator (factory)
2. Concrete creator specifies the concrete product and instantiates an instance, returning it to the Client

It’s a very straightforward pattern, but often beginners will puzzle over why all the work simply to get a class instance? The answer to that question lies more in the larger implementations and re-use of the pattern than it does in the small example used here. However, a good general answer is that it loosely binds the product to the request. If you change the product’s contents, you should not have to change anything else in the pattern. The Client makes the request through an abstraction and really doesn’t care about the details of the product. If the product is changed, the exact same request brings up a different object. However, nothing has to be changed to access the new object. Use the buttons below to download and play the example:

Chapter 2 in our book, and other posts on this blog go into detail about the Factory Method. Here the focus is on abstraction, and the Factory Method is merely used to illustrate the power of abstraction. In order to show the range of products that can be generated from the same abstract interfaces, I used both component UIs and graphic background Shape objects as products.

Using Abstractions and Programming to the Interface

One of the key principles of design pattern programming is,

Program to the Interface and not the implementation….

In order to see both how abstractions are used and how relations work in the n the Factory Method pattern, Figure 2 shows code snippets related to each of the participants (classes and relationships).

Figure 2: Coded Elements of the Factory Method pattern

The Client, Creator and Product

This section shows the code for all of the participants. (You can download it all if you’d like to follow this post using Flash or Flash Builder by clicking the Download button above.) I’d like to start with the Client and then examine the abstract interfaces. We’ll start with the Client:

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

package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var bkdp:Creator=new MakeBackdrop();
		private var btn1:Creator=new MakeButton();
		private var btn2:Creator=new MakeButton();
		private var txtA:Creator=new MakeTextArea();
		private var txtI:Creator=new MakeTextInput();
 
		public function Client()
		{
			addChild(bkdp.factoryMethod(12,15,"0xcc0000"));
			addChild(btn1.factoryMethod(20,30,"Top"));
			addChild(btn2.factoryMethod(20,60,"Bottom"));
			addChild(txtA.factoryMethod(130,30,"Lots of text can go here!"));
			addChild(txtI.factoryMethod(20,100,"Input here"));
		}
	}
}

In looking at the Client, you can see that all requests are through the Creator interface. Because all of the concrete creators (factories) implement the Creator, the objects can be typed to the interface and not the concrete factories. Note that while the Client is requesting concrete Products, products are not even mentioned once. The factoryMethod() takes care of making the request that delivers the product. Think of it as requesting a cup of coffee from a barista. You put in your order for a Café Latte Uruguay Negro (my coffee house is more pretentious than yours). You don’t care about how the barista makes the cup of coffee you ordered; you just know to ask him for the specific product you want, and he’ll take care of it. The Client is doing the same thing.

The Creator (factory) interface is simple because it is abstract. You provide the framework, and the implementations will take care of the concrete elements.

1
2
3
4
5
6
7
8

package
{
	import flash.display.Sprite;
	interface Creator
	{
		function factoryMethod(ex:Number,why:Number,lbl:String):Sprite;
	}
}

As you will see in the concrete implementations of the Creator, you can do a lot of different things with the three parameters.

Next, the Product interface looks very similar to the Creator. In fact, other than different names for the interface and method, they’re the same. The don’t have to be, but in this case they just happen to be. However, as you will see, the implementations of each are different individually and as a group.s

1
2
3
4
5
6
7
8
9

package
{
	import flash.display.Sprite;
 
	interface Product
	{
		function uiProduct(ex:Number,why:Number,lbl:String):Sprite;
	}
}

Going back to the example of the London Tube Map, you can see that the abstractions have very little detail. One “sounds like” it makes something (factoryMethod()) and the other “sounds like” a product (uiProduct()). However, you have enough information to know that each does something different.

The Concrete Implementations: Factories and Products

The final step in working with the abstractions in the interfaces is to make them do something concrete. First, we’ll deal with the factories. The following code creates factories for each of the products:

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

//Make buttons
package
{
	import flash.display.Sprite;
 
	public class MakeButton implements Creator
	{
		private var btn:Product = new UiButton();
		public function factoryMethod(ex:Number,why:Number,lbl:String):Sprite
		{
			return btn.uiProduct(ex,why,lbl);
		}
	}
}
 
//Make backdrop
package
{
	import flash.display.Sprite;
 
	public class MakeBackdrop implements Creator
	{
		private var bkDrop:Product = new UiBackdrop();
		public function factoryMethod(ex:Number,why:Number,lbl:String):Sprite
		{
			return bkDrop.uiProduct(ex,why,lbl);
		}
	}
}
 
//Make TextAreas
package
{
	import flash.display.Sprite;
 
	public class MakeTextArea implements Creator
	{
		private var txtArea:Product = new UiTxtArea();
		public function factoryMethod(ex:Number,why:Number,lbl:String):Sprite
		{
			return txtArea.uiProduct(ex,why,lbl);
		}
	}
}
 
//Make TextInput
package
{
	import flash.display.Sprite;
 
	public class MakeTextInput implements Creator
	{
		private var txtInput:Product = new UiTxtInput();
		public function factoryMethod(ex:Number,why:Number,lbl:String):Sprite
		{
			return txtInput.uiProduct(ex,why,lbl);
		}
	}
}

As you can see, they’re all pretty much the same. They declare instances as a Product but instantiate them as concrete product implementations. There’s not a lot of variety; just the name of the instantiated concrete product.

The concrete products show a great deal of variation, though. This demonstrates the flexibility of abstractions and the loose bindings between a client object and the requested products.

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
87
88
89
90
91
92
93
94
95
96
97

//Button
package
{
	import fl.controls.Button;
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class UiButton implements Product
	{
		private var btnPack:Sprite=new Sprite();
		private var button:Button=new Button();
 
		public function uiProduct(ex:Number,why:Number,lbl:String):Sprite
		{
			button.label = lbl;
			button.addEventListener(MouseEvent.CLICK,btnBusiness);
			button.x = ex;
			button.y = why;
			btnPack.addChild(button);
			return btnPack;
		}
 
		private function btnBusiness(e:MouseEvent):void
		{
			trace("Whatever business you have in mind....");
		}
	}
}
 
//Backdrop
package
{
	import flash.display.Sprite;
	import flash.display.Shape;
 
	public class UiBackdrop implements Product
	{
		private var backdropHolder:Sprite=new Sprite();
		private var backdrop:Shape=new Shape();
 
		public function uiProduct(ex:Number,why:Number,lbl:String):Sprite
		{
			backdrop.graphics.beginFill(int(lbl));
			backdrop.graphics.lineStyle(0,0x0000cc);
			backdrop.graphics.drawRect(ex, why, ex+100, why+100);
			backdrop.graphics.endFill();
			backdropHolder.addChild(backdrop);
			return backdropHolder;
		}
	}
}
 
//Text Area
package
{
	import fl.controls.TextArea;
	import flash.display.Sprite;
 
	public class UiTxtArea implements Product
	{
		private var taPack:Sprite=new Sprite();
		private var txtArea:TextArea=new TextArea();
 
		public function uiProduct(ex:Number,why:Number,lbl:String):Sprite
		{
			txtArea.text = lbl;
			txtArea.width = 200,txtArea.height = 200;
			txtArea.x = ex;
			txtArea.y = why;
			taPack.addChild(txtArea);
			return taPack;
		}
	}
}
 
//Text Input
package
{
	import flash.display.MovieClip;
	import fl.controls.TextInput;
	import flash.display.Sprite;
 
	public class UiTxtInput implements Product
	{
		private var tiPack:Sprite=new Sprite();
		private var txtInput:TextInput=new TextInput();
 
		public function uiProduct(ex:Number,why:Number,lbl:String):Sprite
		{
			txtInput.text = lbl;
			txtInput.x = ex;
			txtInput.y = why;
			tiPack.addChild(txtInput);
			return tiPack;
		}
	}
}

As you can see in the different implementations of the Product object, there’s an immense variation. The Factory Method uses abstraction to make it very easy for the Client to request what’s needed, provide loose binding, and do it while allowing enough room for variation to do whatever the developer wants.

The best part comes when I decide to change something. Suppose I decided I want to make my own TextArea object using a TextField, TextFormat and other coded objects so I don’t have to worry too much about component differences between Flash Professional and Flash Builder. I can simply change my implementation in the concrete product without affecting anything else. In other words, I can make huge programs without having to start all over from scratch.

Thanks abstraction!

It's my first time too!

In learning OOP and Design Patterns, what you’re learning is a set of principles with associated programming patterns. The Template Method is a valuable starting place because it is used to illustrate the OOP/DP principle called The Hollywood Principle. Be sure to go over the more detailed post on the Hollywood Principle, but for here, you just need to become familiar with the idea that higher level components (like parent classes and interfaces) should call lower level components (like concrete classes), but lower level components, should not call higher level components. The principle is called Hollywood, because the casting director tells the budding actor,

Don’t call us, we’ll call you.

The parent class tells the child class the same thing.

Class Diagram

In order to understand a class diagram, you need to understand class relations. If you understand how to work with an UML, you’re ahead of the game; however, if not, we’re prepared a 4-part series to help you understand the UML and the whole concept of relations between pattern participants. Figure 1 shows the class diagram for the Template Method:

Figure 1: Template Method Class Diagram

After you’ve studied the class diagram for a bit, you can see that it’s made up of one abstract class (all italicized bold lettering indicates an abstract class or interface), and one subclass. One of the operations in the abstract class is concrete (Template Method) and the others are abstract (primitive operations). The abstract methods are italicized.

The template method is made up of the steps in an algorithm, some of which are abstract and some that can be concrete. The template method orders the steps in the algorithm, but the concrete subclass provides concrete implementations of the abstract methods using override. The following two buttons provide a preview of Play and all of the files are available for download:

Abstract Classes and Primitives

One of the more poorly defined concepts in computer programming is that of primitives. Usually when we think of primitives, we think of basic data types like numbers, strings and Booleans. However, the Gang of Four parenthetically note that primitive operations are nothing more than abstract methods. For example, the following is an abstract operation (or method):

1
2
3
4
5

protected function DoUI():Sprite
{
    throw new IllegalOperationError("Must override");
    return null;
}

Because ActionScript 3.0 has no abstract classes or methods, you have insure that the abstract methods will not be directly instantiated, and one way to do that is to add the illegal operation line. Further to have the proper signature, the method must include some kind of return statement, and a null value does the trick. In the concrete implementation, each primitive operation is overridden and provided concrete operations.

Within the abstract class, you can have both concrete and abstract methods. One of the advantages of an abstract class (compared with an interface) is that abstract classes can have some concrete methods. For example the following template method uses two primitive operations and a concrete one. It’s just is to order the steps of the algorithm, which in this case has three:

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

...abstract class..
 
public function templateMethod()
{
	DoLogo();
	DoUI();
	DoInfo();
}
 
protected function DoUI():Sprite
{
	throw new IllegalOperationError("Must override");
	return null;
}
 
protected function DoInfo():TextField
{
	throw new IllegalOperationError("Must override");
	return null;
}
 
protected function DoLogo():Sprite
{
	var logo:Sprite=new Sprite();
	return logo;
}
 
...abstract class

So let’s stop a second and consider why and how we’d use a Template Method design based on the following:

1. An abstract class
2. A method that orders the steps in an algorithm
3. At least one abstract method that is overridden by a concrete class that implements the abstract class.

The abstract class affords the programmer flexibility when similar algorithms are used again and again but with slightly different implementations. For example, you may find yourself using a “page algorithm.” The page algorithm loads your logo, creates a UI and then creates content. The logo loading part is going to be the same as you use your logo over and over again. However, the UI and content can vary in several different ways. For that, you need flexibility.

Page Arranger

To get started on the algorithm for a page arranger, we’ll start with the abstract class which is named IServices. One convention you will find in OOP is using an “I” prefacing all Interfaces. I like to do the same thing with abstract classes because other than the concrete properties and methods, you should think of them as a type of interface. (If you’re just getting started in OOP and Design Patterns, you might want to check out Beginners Start to see where the files go in Flash and Flash Builder.)

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

package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
	import flash.net.URLRequest;
	import flash.display.Loader;
 
	//Abstract class. Do not instantiate directly
	//Extend the class for concrete child classes
 
	public class IServices extends Sprite;
	{
 
		private var logoPix:URLRequest=new URLRequest("logo.swf");
		protected var uiPix:URLRequest;
		protected var infoPix:URLRequest;
		private var logoLoader:Loader=new Loader();
		protected var uiLoader:Loader=new Loader();
		protected var infoLoader:Loader=new Loader();
		private var page:Sprite=new Sprite();
		private var logoSprite:Sprite=new Sprite();
		protected var uiSprite:Sprite=new Sprite();
		protected var infoSprite:Sprite=new Sprite();
 
		public function templateMethod():Sprite
		{
			page.addChild(DoLogo());
			page.addChild(DoUI());
			page.addChild(DoInfo());
			return page;
		}
 
		protected function DoUI():Sprite
		{
			throw new IllegalOperationError("Must override");
			return null;
		}
 
		protected function DoInfo():Sprite
		{
			throw new IllegalOperationError("Must override");
			return null;
		}
 
		protected function DoLogo():Sprite
		{
			logoLoader=new Loader();
			logoLoader.x=0;
			logoLoader.y=0;
			logoLoader.load(logoPix);
			logoSprite.addChild(logoLoader);
			return logoSprite;
		}
	}
}

In the abstract class IServices, you can see two abstract methods (primitive operations), and two other methods—DoLogo and templateMethod. The DoLogo is going to be the same assuming that the company keeps the same logo; so you might as well set it up and let the child classes reuse it when they extend the abstract class. However, the UI and information may change, and so both of the methods for what they may include are left up to the concrete implementation.

Next, enter the concrete implementation of the abstract class. In the following you will see that both of the abstract methods are not implemented.

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

package
{
	import flash.display.Sprite;
	import flash.net.URLRequest;
	import flash.display.Loader;
 
	public class ConcreteService extends IServices
	{
		override protected function DoUI():Sprite
		{
			uiPix=new URLRequest("UI.swf");
			uiLoader=new Loader();
			uiLoader.x=0;
			uiLoader.y=110;
			uiLoader.load(uiPix);
			uiSprite.addChild(uiLoader);
			return uiSprite;
		}
 
		override protected function DoInfo():Sprite
		{
			infoPix=new URLRequest("info.swf");
			infoLoader=new Loader();
			infoLoader.x=150;
			infoLoader.y=110;
			infoLoader.load(infoPix);
			infoSprite.addChild(infoLoader);
			return infoSprite;
		}
	}
}

Keeping in mind that you never implement an abstract class, but you want to program to the abstract class (think interface), you will need a client class to request the use of the concrete implementation. However, by declaring the requesting instantiation through the abstract class, you can keep the binding loose. So the variable tm is typed to IServices but instantiates ConcreteService.

1
2
3
4
5
6
7
8
9
10
11
12

package
{
	import flash.display.Sprite;
	public class Client extends Sprite
	{
		private var tm:IServices=new ConcreteService();
		public function Client()
		{
			addChild(tm.templateMethod());
		}
	}
}

As you can see, there’s not much work for the Client. All it has to do is to use addChild to place the returned Sprite object to the display area. The templateMethod() operation is wholly inherited from the IServices class, but at the same time the ConcreteService class allows flexibility of what goes into the DoInfo and DoUI methods.

Play around with this example. The best way is to create some .swf files that you can use instead of the ones provided for download on this post. You’ll begin to see how flexible this design pattern is and how easy it is to use.

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

Lazy Bones

There’re more ways than one for being lazy with design patterns. In this post we’ll look at two: First we’ll see where you can take a program based on the Factory Method and reuse it for another program. Secondly, we’ll see where we put lazy instantiation in a Factory Method. That’s double lazy! So Homer Simpsons of the world unite! This is the design pattern for you. D’oh! (In the past we’ve examined lazy initialization, but in this post we’ll look at lazy instantiation.)

Last week we had our first online presentation thanks to the Adobe users in Brazil. However, many missed it, and I promised to provide everyone with the materials we covered. Besides, since this is a discussion of a Factory pattern we can reuse our Factory Button! (Even this post is lazy!) Click the two buttons to see the apps with two different implementations. Then you can download the two apps and the PowerPoint file from the presentation by clicking the download button.

Southern Brazil

New England

So you may be thinking that both of the applications are doing pretty much the same thing—placing objects on the screen. That’s true. Rocket science it’s not. However, the nature of the classes is such that we have a wide range of options with the objects. As the applications are currently laid out, it’s easy to change the objects and the collection of objects without breaking the application. Let’s see how.

Talk to the Factory

The Factory Method design pattern is made up of a Creator (Factory) interface with concrete creators that instantiate concrete products represening implementations of a Product interface. The Creator contains an abstract FactoryMethod() operation that each concrete creator implements. Figure 1 shows a typical factory pattern with different shapes implied from the concrete creators and products. The shapes are representatives of any objects that the developer wants to request using the FactoryMethod() operations.

Figure 1: Factory Method Class Diagram

The class diagram accurately portrays the role of the concrete factories—they instantiate the products indicated by the dashed arrows. The factories are more like car dealerships than they are “factories.” The dealerships order (instantiate) a completely built car. They don’t build them—they get them. If you have parameterized products; then perhaps you can think of the instantiation process as one where the objects are “built” by the concrete factories that pass the arguments, but in this example, think of the concrete creator (factory) classes as “auto dealerships” and not “auto factories.”

Figure 2 shows how the client makes its request and the links between the participants:

Figure 2: Client makes request

To get a better idea of the details of the client’s request, look at Figure 3. The object being requested is a Brazillian state named Paraná (not to be confused with the fish, piranha or paraña). Note that the variable named pirana is typed as a Factory—the interface. Then the request is made by instantiating a concrete factory class, MakeParana, an implementation of the Factory abstract class. (Programming to the interface; not the implementation.)

Figure 3: Client makes request using a Factory object

To help get a better idea of how that request is made in the larger context of a Factory Method design pattern, Figure 4 shows just those classes involved in the request in a file diagram. The request is sent to the MakePirana concrete factory through the Factory interface (an abstract class). The factory instantiates a concrete Product instance named Pirana.

Figure 4: Files used in Pirana object request

If I wanted to change the character of the Pirana object to something else, the Client could care less. It just makes the request to the concrete factory object and lets the factory worry about instantiating the object. Let’s say that instead of the state of Pirana, I wanted to use the design pattern to get the state of Connecticut. I wouldn’t change the request to the factory; I’d change the object that the factory instantiates and returns to the Client.

The Abstract Factory and Product

Both of the interfaces in this implementation of the Factory Method are made up of abstract classes. The Factory class holds a reference to the Product class and an abstract factoryMethod() operation. The details of the factoryMethod() are left up to the concrete factories to implement. Figure 5 shows the Factory abstract class:

Figure 5: The Factory Interface (abstract class)

Nothing is declared and the protected variable, product is only declared as a Product type. Product, is an abstract class and so the product variable will have to be instantiated as a concrete implementation of Product and not Product itself. (You cannot instantiate an abstract class.)

The Product class is similar in that it is abstract and nothing is implemented. Figure 6 shows how it is built:

Figure 6: The abstract class Product

Originally, I had the Product class subclass Sprite, but I realized later that I did not need to do that. Each of the product objects were already children of the Sprite class, and so I had all of the properties and methods in the Sprite class I needed. By not subclassing the Sprite, the Product class is looser because it has no binding through subclassing. Importing the Sprite package is enough to reference the Sprite as the return type of the getObject() method and objectNow property.

Implementing the Concrete Factories (with Lazy Instantiation) and Products

All that’s left is to implement are the Factory and Product interfaces (abstract classes). The objects that are used to actually show images on the screen are Library Sprites. I just drew the different states (estados) using Flash tools and converted them into MovieClip symbols. Then, I converted the MovieClip classes into Sprite classes by changing the Base class from flash.display.MovieClip to flash.display.Sprite.

The concrete factory that calls the requested Parana state, checks to see if the product already exists, and if not, produces one. Then, using the product object it uses the getObject() method to get the requested product. Figure 7 shows how each of the concrete factories are coded–the only difference being that they instantiated different concrete products:

Figure 7: Concrete factory instantiates requested object

We can see the lazy instantiation in the conditional statement that is looking for an uninstantiated product, and if the product does not exist as an instance, it creates one. The product property is inherited from the Factory abstract class. The product is initialized in the Factory class as a Product type—that’s why you don’t see any data type assigned to the product in the concrete factory. So while the product is unimplemented, it has been initialized. This binds the product only to the Product interface and not any single product implementation. As a result, the product object can be used to instantiate any of the concrete properties. This is what makes programming to the interface and loose coupling so valuable.

Finally, we come to the concrete products. Each products extends the Product class and implements the getObject() function. The objNow property (inherited from the Product abstract class) instantiates a Sprite object from the Library. The Sprite can come from any source where a Sprite can be stored. The important fact is that the object is a Sprite and has key Sprite properties and methods. In this case, all we need are the horizontal (x) and vertical (y) properties. Figure 8 shows how the Parana product is created;

Figure 8: Concrete Product class

The important features of this example lies not what was done initially, but rather how it was reused to create a similar application for a different region. Likewise, the concrete factory and product classes follow the OOP single responsibility principle—each has a single responsibility that is loosely bound and re-useable. For example, the following two classes show how the same application was reused to create the New England version of the same program:

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

//Connecticut Factory
package
{
	import flash.display.Sprite;
 
	public class MakeConn extends Factory
	{
		public override function factoryMethod():Sprite
		{
			if(! product)
			{
				product=new ConnProd();
			}
			return product.getObject();
		}
	}
}
 
//Connecticut Product
package
{
	import flash.display.Sprite;
	public class ConnProd extends Product
	{
		public override function getObject():Sprite
		{
			objNow=new Conn();
			objNow.x=188.45, objNow.y=321.75;
			return objNow;
		}
	}
}

As you can see, the concrete factory and product are the same as those for the Brazilian states. The Factory and Product abstract classes are identical.

One Year of Programming Experience 20 times

You may have heard programmers proclaim,

I’ve been programming for 20 years, blah, blah, blah….

While such programmers may have a wealth of knowledge from their experience, they may have just been doing the same kind of programming for 20 years. Years ago, I heard a police officer remark about one of the older (and not too effective) officers as a

…guy who had 1 year experience 20 times.

Essentially the police officer who made that comment was saying that the old-timer never tried to keep up his skill levels with new knowledge. He just kept doing the same old thing again and again. That can happen at any age, and in computing, it’s a recipe for disaster.

When I discovered OOP and then Design Patterns, I realized that I had been like that old cop who kept doing the same thing over and over again. To be sure, I learned several new languages ranging from machine/assembly languages to high level languages like BASIC and even PostScript—and just about everything in between. However, while different computer languages have different lexicons, sequential and procedural programming are still S&P programming no matter what language you’re in.

To break those (bad) habits, design patterns and the OOP that goes with them, forced me to think in different ways approaching programming problems. Instead of thinking in terms of a series of steps, I started to think in terms of loosely bound objects communicating with one another. The only sequences were little ones inside the methods and assigned values to properties—and many of those were just for using other objects. The design patterns themselves became “cheat sheets” where I could more easily envision how objects could be arranged to communicate and achieve a goal.

This particular example somehow brought many of the lessons I’ve learned from design patterns home. It wasn’t until the last minute that I decided to make another regional map where I could demonstrate re-use of design patterns (Southern Brazil to Northeast US). Because I waited until the last minute, that was about all the time I had—that last minute. However, once I finished the graphic sprites, everything else fell into place. I just re-used the structures and the communication systems from the original app. It may sound funny to voice it, but programming to the interface really saved my bacon. Here I had a whole new set of objects I had to get singing in the same choir, but I knew that as long as I paid attention to the interface, everything would work together—that’s 27 classes scaled down to 17 for a new application.(That’s not even counting the Sprite classes with the graphics!) And everything worked out fine.

Try doing that without a design pattern. Spaghetti city!

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?

Unfortunately, the concept of inversion is only half the story and is used in reference to programming structures where a higher-level module depends on a lower-level module. One might be led to believe that the inversion occurs where lower level modules depend on higher-level modules only. Actually, the principle holds that

all modules of a program should depend on abstractions

Maybe a better name for the principle would be the Abstraction Dependency Principle. In any event, program modules should all depend only on abstractions. If you look at Figure 1 you can see a simple example where a Client instantiates a concrete class but depends on the abstract class for typing. Further, the concrete classes depend on the abstract class for implementation. Aggregations and associations would depend on the abstract base class instead of the concrete classes as well.

Figure 1: Depending on Abstractions
As you can see in both the diagram and code snippets, all dependencies are on the Abstract class. That’s what the principle means at its core. It’s not a difficult one, and it overlaps with lots of other principles we’ve discussed on this blog and in our book.

The Devil is in the Details

A corollary to dependency inversion is what might be called detail inversion—not that anyone actually calls it that. The principle is,

Details should depend on abstractions, and abstractions should not depend on details.

As you can see in Figure 1, the details in the two concrete classes depend on the implementations of the abstract class. Likewise, the details of instantiation depend on the nature of the Client’s request. If you’ve been reading about the different design patterns on this blog and in our book, this corollary may appear to be almost too self-obvious to state. However, if this is the first OOP principle you’ve considered, it may not be as clear.

Consider an abstract class called Fruit. As you know, the details of different kinds of fruit are many—from kumquats to kiwi fruit and bananas to blueberries. So, while you can put the general characteristics of fruit in an abstract class (e.g., berry, pome, drupe), the details are in the concrete implementations (e.g., apples and oranges). However, the implementations depend on the general properties in the base abstract class; not the other way around.

Where to Find Dependency Inversion in Design Patterns

Robert C. Martin’s series of articles in his Engineering Notebook written for the C++ Report came out around the same time as the Gang of Four’s Design Patterns book. (Roughly the period of late 1995 to early 1996). However, Martin along with OOP thinkers like Grady Booch and GoF were all thinking along the same lines. Martin makes references to OOD for Object Oriented Design—clearly differentiating it from OOP, and he references the GoF book, which was brand new at the time he was writing about dependency inversion. What all of these software engineers had in common was that their emphasis had shifted from just programmingto the broader concept of programming design.

So while you’ll not find a reference to dependency inversion in GoF, you will see it applied in design patterns. For example, if you look at the Strategy design pattern, you will see an almost perfect example of dependency inversion. The Client makes requests through the abstract Context, which in turn holds references to the abstract Strategy. Any references to the concrete classes are all through an abstract interface or class. That is, the references are typed as abstract classes or interfaces. Likewise Martin uses a Template Method and Adapter design patterns to illustrate dependency inversion. Suffice it to say that the thinking and writing about design patterns in the early 1990s through OOPSLA conference presentations and papers began to coalesce around the mid-1990s in publications focusing on the design aspect of programming. The programming principles that emerged from that era were all looking for ways to express the importance of strong but loose designs for reusability and adding functionality.

Into the Lunch Bucket

Now that you have a sense of dependency inversion, you can put it into your lunch bucket and take it to work. You may be thinking that the other principles pretty much encompass what is included in the Dependency Inversion Principle, and you’d be right. When Robert C. Martin developed the concept, he noted that the principle encompasses both the Open/Closed and Liskov Substitution Principles. So any sense of déjà vu you may have detected is grounded in reality. Also, if you are interested in a related concept that will be discussed in a later post, you might want to look into Martin Fowler’s Dependency Injection concept. (Be careful not to get your Martins mixed up!). Likewise, Miško Hevery has a great video and article on dependency injection.

Program to an interface, not an implementation

Simply put, the Gang of Four urges programmers to declare variables only to abstract classes and interfaces and not concrete implementations. You never want to type your instance as a concrete class derived from an interface or abstract class—only to the interface.

Okay, you may be thinking that we already covered this principle in our book. That’s true. We did in both the introduction (pp. 45-49) and in part of the chapter on the Observer design pattern (pp. 285-288.) We also had a lot of examples, and so why rehash the same principle here? The following reasons seemed compelling enough to warrant additional discussion:

• Includes dynamic binding
• Closely tied to polymorphism
• Built into Creation design patterns
• Easy to ‘take to work’

Before starting, we’ll use the concept of an interface to refer to programs that use either abstract classes or ActionScript 3.0 interface. So, if you see a reference to an interface, it could well be an abstract class. It’s the concept of an interface that’s important; not the ActionScript 3.0 interface statement.

As you read this, you may hear echoes of the Liskov Substitution Principle (LSP). I’m really not sure what relation there is between the LSP and the first GoF principle. Suffice it to say that LSP is part of the back-story (as they say in Hollywood), but only part. During the 1980s and 1990s when a lot of the OOP and Design Patterns concepts were being developed and presented at OOPSLA, ideas were shared. Further, GoF references Abstraction and Specification in Program Development by Barbara Liskov and John Guttag (McGraw-Hill, New York, 1986) so Gamma and his associates were aware of Liskov’s work. But to say that this principle was derived from LSP is a leap that I’m not willing to take. However, I certainly see no contradiction between LSP and GoF’s first principle.

Dynamic Binding, Polymorphism and Interfaces

Polymorphism has been discussed elsewhere on this blog, and we all know it is one of the pillars of OOP. This first principle of design patterns is tied into polymorphism. In order to follow the path from interfaces to polymorphism, we need to start with an operation’s signature. As you know, a signature is made up of the following:

• operation’s name
• objects it takes as parameters
• return value

In this context we can discuss interfaces as all of the operations in an object. For the most part, an object as used by GoF refers to a class and not an instance of a class as the term object is conventionally used. (I won’t belabor the meaning of signatures and interfaces here, but if you want more details on both concepts, see the discussion beginning on page 19 of our book.)

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Design patterns help you set up interfaces and use polymorphism in organizing your program. The more you look at the different principles of OOP, the more you can see how these principles are maintained and presented in design patterns. Key are ActionScript 3.0 pure interfaces and abstract classes. All operations in an interface are abstract, but an abstract class can defer some or all implementations to derived classes (subclasses.) Thus, the abstract class is more flexible than the pure interface, but both serve as interfaces

Reducing Implementation Dependencies

Gamma and his associates spell out two key benefits of manipulating objects solely in terms of the interface (of either pure interfaces or abstract classes).

1. Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect.

2. Clients remain unaware of the classes that implement these objects. Clients only know about the abstract class(es) defining the interface. (GoF, p. 18)

The whole purpose is to build functional structures but to keep them loose enough for change and reusability. Obviously you have to instantiate concrete classes, but by using the abstract class interface, (instead of the concrete classes’) you provide flexibility in the implementation. All design patterns in the Creational category [Factory Method, Abstract Factory, Prototype, Builder and Singleton*] essentially force you to create your programs in a way that follows this principle. (*I have serious questions as to the Singleton’s ability to do anything very useful along these lines. See this post for details.)

Implementation Lunch Bucket Rule

While GoF’s statement of the principle is very clear once you understand what they mean by an interface, we might be able to re-word it for an even simpler rule to take to work.

Type all objects to the interface of the parent class and never to the child class

Of course the parent and child class share an interface, but the child class (subclass) has concrete implementations.

The best part about this rule is that it is automatically enforced in all creational patterns. So, besides having a simple rule to work with (and bring to work) you have plenty of patterns that automatically set up your program to follow this rule.

The 1987 OOPSLA keynote address by Barbara Liskov contained what has become known as the Liskov Substitution Principle (LSP). Essentially, the principle holds that

If a Client is using a reference to a base class it should be able to substitute a derived class for it without affecting the program’s operation 

(Actually Dr. Liskov said something more like:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

but I’m not about to…)

If the Client has an object of a certain type, it should be able to substitute a derived object of the same type. For example, suppose you have an abstract class named Automobile and from that class you have subclasses of Ford, Toyota, and Peugeot. Your Client has an object, myAuto:Automobile. The myAuto object can be any of the subclasses, and if a substitution is made for any one of them everything keeps on working without a problem and the change is unknown to the Client. So if you substitute a Ford for a Toyota, the Client can work with the objects without having to adjust for the change. What’s more, if you want to add a Fiat class as a subclass of Automobile, the myAuto object handles it with nary a whimper.

The one caveat is that the subclasses must all honor the contractual conditions of the parent class. So, any methods in the parent class must be functioning in the subclass (aka, derived class.)

Now you may be thinking, So what? If you’re at all familiar with other principles of OOP and Design Patterns, this principle may sound vaguely familiar, but what is the importance of this concept/principle/idea? It is this: Because the Client is unaware of the concrete class that the object may implement, the structure is far more resilient. Not only can the same structure be reused, it can be changed, updated and generally fiddled with without easily breaking anything. (Think of adding more car manufacturers to the Automobile class.) As far as the Client is concerned, as long as the interface rules are followed with the object, everything is hunky-dory.

A Simple Practice

As a principle, the Liskov Substitution Principle is easy to carry around in your pocket. If you write the following line in your Client (or even your Factory) you’re doing something wrong:

myObj:SubClassA = new SubClassA();

You know that another subclass of the same base class cannot be substituted for SubClassA. If you attempt to substitute SubClassB for myObj, it will fail. Now, instead, all you have to remember is to write,

myObj:ParentClass = new SubClass();

That’s (just about) it! Well, one more thing. The parent class needs to be an abstract class or an interface. Now, that’s it! How difficult is that to remember?

LSP in the Weird World

In looking at examples of the LSP principle, the two that pop up the most are the rectangle/square and ellipse/circle conundrums. We’ll use the rectangle/square example and try to provide two different alternatives to illustrate programming with LSP and without LSP.
Beginning with the geometric observation, all squares are also rectangles, we’re likely to create a structure like that shown in Figure 1:

Figure 1: Square is a child of Rectangle

After all, we can envision a square as nothing more than a rectangle with equal sides. So an operation such as,

makeRectangle(w,h);

is an effective way to make either a square or rectangle. We add the Square class simply to examine the LS Principle; otherwise creating rectangles or squares would be accomplished using the makeRectangle(w,h) method making sure that w and h are equal when making squares. The inheritance path clearly indicates that a Square object IS A Rectangle. (That is, the two have an IS A relationship.) However, because Rectangle is a concrete class if I substitute Rectangle for Square, I’m going to have to change the type. I cannot substitute an instance of Rectangle for an instance of Square. This violates the Liskov Substitution Principle.
Now, consider Figure 2. Instead of having Square as a child of Rectangle, both Square and Rectangle are children of the abstract class Boxes.

Figure 2: Abstract Class is Parent of both Squares and Rectangles

If I have an instance of Boxes, I can substitute either Square or Rectangle for the instance. In looking at an example, the Client is where we can expect to see the substitution principle at work. In the following example, the Client has a single object (subThis) typed as Boxes. However, that single object can gingerly create either a square or rectangle without the Client knowing the difference. It is designed to illustrate LSP.

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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var subThis:Boxes;
		private var rec:Button=new Button();
		private var squ:Button=new Button();
 
		public function Client()
		{
			//Constructer adds buttons
			rec.x = 100,rec.y = 50;
			rec.width = 65;
			rec.addEventListener(MouseEvent.CLICK,doRec);
			rec.label = "Rectangle";
			addChild(rec);
 
			squ.x = 170,squ.y = 50;
			squ.width = 65;
			squ.addEventListener(MouseEvent.CLICK,doSquare);
			squ.label = "Square";
			addChild(squ);
		}
 
		private function doSquare(e:MouseEvent):void
		{
			if (subThis)
			{
				removeChild(subThis);
			}
			subThis=new Square();
			subThis.createBox(70,0);
			subThis.x = 100,subThis.y = 100;
			addChild(subThis);
		}
 
		private function doRec(e:MouseEvent):void
		{
			if (subThis)
			{
				removeChild(subThis);
			}
			subThis=new Rect();
			subThis.createBox(100,70);
			subThis.x = 100,subThis.y = 100;
			addChild(subThis);
		}
	}
}

The Client has two methods to create either a square or rectangle. However, both methods use the object subThis typed as Boxes. Using Boxes.createBox() (subThis.createBox()) the Client substitutes the Square and Rectangle for the Boxes object. Everything works smoothly. The way the program is set up when one is used, the box image changes from a square to a rectangle (or vice versa), but if you wanted, you could create as many as you want and splash them all over the stage. Figure 3 shows what you will see in the current setup.

Figure 3: Substituting Square and Rectangle Subclasses for Boxes Object

With this simple program, you should be able to see the ramifications for larger programs. In fact, the more your program grows, the more important LSP becomes. If you know that you can substitute any derived class for a base class, you are less likely to have unpleasant surprises. As a program grows and changes, you will have more modules, more objects, and more methods that need to interact in a program. The LSP helps keep those relations functional.

The Base Class

After working with the LS Principle, I wondered,

…is there any reason to create a concrete base class? 

The answer is no.

Not a single design pattern has a structure with a concrete parent class.

What do I ever need a concrete parent class for? I can load up a parent class with functionality that can be used with subclasses, but I need some kind of wiggle room for the subclasses to extend the base class. Following the open/closed principle (“Open for extension. Closed for modification”), I can extend with added functionality from a superclass but I don’t want to modify it.

The following base class (Boxes) has a single method and imports the essential Sprite class needed for the graphics. The concrete classes override the function but they both inherit the Sprite class embedded in the base class.

1
2
3
4
5
6
7
8
9
10
11
12
13

package
{
	//abstract class
	import flash.display.Sprite;
 
	public class Boxes extends Sprite
	{
		public function createBox(w:Number,h:Number):void
		{
			//Abstract content
		}
	}
}

In an odd choice, ActionScript 3.0 has Graphic methods for a circle (drawCircle) and an ellipse (drawEllipse), but not for a square –only a rectangle (drawRect). In order to create an equivalent square and rectangle pair, I used the new Player 10 ActionScript 3.0 drawPath() method. (If you’re using Flash CS3 or versions of Flex prior to 3.2, alternative Square and Rectangle classes can be found at the end of this post.) In looking at the concrete classes, there’s not much difference other than the second parameter in the Square class is a dummy variable that is happy with number you stick there. The first parameter (h) is passed to a side variable (s) and only that single value determines the width and heights, which, of course, must be equal. First, you have the Rect class:

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

package
{
	public class Rect extends Boxes
	{
		private var recCmds:Vector.;
		private var recCoord:Vector.;
 
		public override function createBox(w:Number,h:Number):void
		{
			recCmds = new Vector.(5,true);
 
			recCmds[0] = 1;
			recCmds[1] = 2;
			recCmds[2] = 2;
			recCmds[3] = 2;
			recCmds[4] = 2;
 
			recCoord = new Vector.(10,true);
 
			recCoord[0] = 0;//x
			recCoord[1] = 0;//y
			recCoord[2] = w;//width
			recCoord[3] = 0;
			recCoord[4] = w;//width
			recCoord[5] = h;//height
			recCoord[6] = 0;
			recCoord[7] = h;//height
			recCoord[8] = 0;
			recCoord[9] = 0;
 
			graphics.beginFill(0x990000);
			graphics.drawPath(recCmds, recCoord);
		}
	}
}

Next, the Square class is similar, but notice the “dummy” label for the second parameter.

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

package
{
	public class Square extends Boxes
	{
		private var recCmds:Vector.;
		private var recCoord:Vector.;
		private var s:Number;
 
		public override function createBox(w:Number,dummy:Number):void
		{
			s = w;
 
			recCmds = new Vector.(5,true);
 
			recCmds[0] = 1;
			recCmds[1] = 2;
			recCmds[2] = 2;
			recCmds[3] = 2;
			recCmds[4] = 2;
 
			recCoord = new Vector.(10,true);
 
			recCoord[0] = 0;//x
			recCoord[1] = 0;//y
			recCoord[2] = s;//width
			recCoord[3] = 0;
			recCoord[4] = s;//width
			recCoord[5] = s;//height
			recCoord[6] = 0;
			recCoord[7] = s;//height
			recCoord[8] = 0;
			recCoord[9] = 0;
 
			graphics.beginFill(0x009900);
			graphics.drawPath(recCmds, recCoord);
		}
	}
}

As you can see, no rocket science is involved in either the drawing classes and their base class or the Client class. A single method is used to generate either, and the only real difference between the child classes is the enforcement of the equal width and height in the Square class.

LSP Lunch Bucket Rule

What can we take to work with the Liskov Substitution Principle? It’s nice to know and understand why the principle is in place, but who needs to have all of the implied tentacles of the principle rattling around in your head—especially considering the way Liskov stated it. We know the principle as you should be able to substitute any derived class from a base class where an instance of the base class exists. After further examination, the only way to do that is to use an abstract class or interface for all of your inheritance and implementations. Put more succinctly, the Lunch Bucket Rule is,

Only subclass from abstract classes. Do not inherit from concrete classes.

That’s easy enough to remember. Put that in your head and see if it helps move an OOP and Design Pattern agenda along at work.
\- – - – - – - – - – - — – - – - – - – - – - — – - – - – - – - – - — – - – - \

Flex client and Rect and Square Classes for Flash CS3 and Flex prior to 3.2

First, if you’re using Flex, you might want to use the following mxml program for your client (Ignore the Client.as class if you do):

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

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
	<mx:Script>
		<![CDATA[
		import flash.display.Sprite;
 
		private var subThis:Boxes;
 
		private function doSquare():void
		{
			if ( subThis && rawChildren.contains(subThis) ) rawChildren.removeChild(subThis);
 
			subThis=new Square();
			subThis.createBox(70,0);
			subThis.x = 100,subThis.y = 100;
			rawChildren.addChild(subThis);
		}
 
		private function doRec():void
		{
			if ( subThis && rawChildren.contains(subThis) ) rawChildren.removeChild(subThis);
 
			subThis=new Rect();
			subThis.createBox(100,70);
			subThis.x = 100,subThis.y = 100;
			rawChildren.addChild(subThis);
		}
 
		]]>
	</mx:Script>
	<mx:Button x="100" y="76" label="Square" click="doSquare()" id="squ"/>
	<mx:Button x="200" y="76" label="Rectangle" id="rec" click="doRec()"/>
</mx:Application>

Here’s the Rect class:

1
2
3
4
5
6
7
8
9
10
11

package
{
	public class Rect extends Boxes
	{
		public override function createBox(w:Number,h:Number):void
		{
			graphics.beginFill (0x990000);
			graphics.drawRect (0,0,w,h);
		}
	}
}

And now the Square class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package
{
	public class Square extends Boxes
	{
		private var s:Number;
 
		public override function createBox(w:Number,dummy:Number):void
		{
			s=w;
			graphics.beginFill (0x009900);
			graphics.drawRect (0,0,s,s);
		}
	}
}

This is one of the few design patterns that I worked up directly from the class diagram and from concepts in GoF. Normally, I like to look at some examples, done in Java or C#, but not this time. As you will see in Figure 1, the pattern appears to be fairly daunting, but I found it to be eminently practical, and it seemed to be a direct response to questions that I had about the Factory Method design pattern (See Chapter 2 for an in-depth explanation of the Factory Method.) You can download the entire example here before continuing if you wish.

 Let me start with the gist of the example from GoF and provide something more concrete that’s likely to be a typical kind of issue Flash and Flex developers deal with. Imagine a project where your designers have created general templates for a business site and another for a game site. Their templates include a SWF background and a set of buttons for a UI. The buttons are wholly programmed and require nothing in the Library, and so using them for either Flash or Flex is fairly simple.

 You want to keep your design loose, and so you decide that a factory will be helpful. However, clearly you will need a factory to create instances of both buttons and the background template. Further, you want your products to derive from an abstract class to give you as much flexibility as possible. In the example here, you will need an abstract product for buttons and another for backgrounds. You also want your factory abstract enough to make requests for sets of objects from the different products. For example, you want your factory to deliver both a set of buttons and a background that are matching pairs. You don’t want a set of buttons for a game site with a background for a business site, but rather you want the buttons to match your background—business buttons with a business background and game buttons with a game background. This is a job for the Abstract Factory.

 Figure 1 shows the class diagram. In looking at the “create” lines (dashed lines), think of them as working with matched sets. The Client requests a business set; and it gets both a business product for buttons and another product for background. So while the diagram may look busy, it really is doing something that makes sense on a basic level. That is, the design is geared to sets; of products with factories that create the requested sets rather than individual objects.

Figure 1: Abstract Factory Class Diagram
Note that Figure 1 shows that both concrete factories create instances from each of the child classes of the two abstract product classes. You can very quickly see the practicality of this when you substitute some concrete elements for the more general conceptual names.

Buttons and Backgrounds

A simple project to use as an example is a program that loads a buttons-background pair. The buttons are made using the SimpleButton class, and the backgrounds are SWF files created using Flash. Figure 2 shows the class diagram for the sample project:

Figure 2: Example of Abstract Factory
The two button classes (RoundBtn and RecBtn) dip into a buttons folder where they pick up the buttons. These other classes not in the diagram can be thought of as helper or utility classes. Likewise, the two SWF files might be considered utility objects in the mix. Figure 3 shows the actual files and folders arranged in the class diagram.

Figure 3: File Diagram of Abstract Factory

No lines go to either the buttons folder or the two .swf files. They’re really not part of the pattern but rather resources (helpers if you wish) for the different participants. If we did add lines, they’d be dashed ones to indicate that the product subclasses create instances of the helpers.

The Client

The Client is a busy object in this design. It holds references not only to the abstract factory (AbFactory) it also holds references to all abstract product classes. The important point here is that by holding references to an interface (the abstract classes), the Client doesn’t get bogged down with specific dependencies. If any of the concrete classes change, the client’s references can handle it. Let’s take a look at the code for this key participant in the pattern:

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

{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var busFactory:AbFactory;
		private var gameFactory:AbFactory;
 
		private var btn1:ProductA;
		private var btn2:ProductA;
		private var btn3:ProductA;
 
		private var gameWall:ProductB;
		private var busWall:ProductB;
 
                private var btnX:int;
 
		public function Client()
		{
 
			busFactory=new BusinessFactory();
			btnX=20.9;
			busWall=busFactory.createProductB();
			addChild(busWall);
 
			btn1=busFactory.createProductA("Accounts");
			addChild(btn1);
			btn1.x=btnX, btn1.y=224;
 
			btn2=busFactory.createProductA("Factory");
			addChild(btn2);
			btn2.x=btnX, btn2.y=272;
 
			btn3=busFactory.createProductA("Production");
			addChild(btn3);
			btn3.x=btnX, btn3.y=320;
 
			//Move block comment symbols to change
                       // from business to game
/*
			gameFactory=new GameFactory();
			btnX=18;
			gameWall=gameFactory.createProductB();
			addChild(gameWall);
 
			btn1=gameFactory.createProductA("Fire");
			addChild(btn1);
			btn1.x=btnX, btn1.y=224;
 
			btn2=gameFactory.createProductA("Move");
			addChild(btn2);
			btn2.x=btnX, btn2.y=272;
 
			btn3=gameFactory.createProductA("Hide");
			addChild(btn3);
			btn3.x=btnX, btn3.y=320;
 
			// Don’t forget to move close comment block symbol
*/
		}
	}
}

The first item to note is how the Client class holds references to both the abstract factory and abstract product:

private var busFactory:AbFactory;
private var gameFactory: AbFactory;
…
private var btn1: ProductA;
private var btn2: ProductA;
private var btn3: ProductA;
…
private var gameWall: ProductB;
private var busWall: ProductB;


In this particular example, the choices for a business or game site are separated by commenting out one of the sites. In this case, the business site appears. Of course you can add a UI that would call up one or the other, but this approach seemed a bit clearer. To see one or the other, just change the position of the comment characters (/* and */). So using the default comment characters, when you test the program, Figure 4 shows what you’ll see initially:

Figure 4: Business Site and Buttons

By moving the comment symbols to block out the business options and opening the game options, you’ll see an entirely different background and button set. Figure 5 shows the dramatic difference.

Figure 5: Game Site and Buttons

By comparing Figures 4 and 5, you can see an entirely different set of buttons and background. The square in the middle rotates to further distinguish the game products from the business ones. (I know, gratuitous use of animation. Sorry.)

The Abstract and Concrete Factories

The abstract factory allows far more flexibility than a concrete factory. Because the backgrounds and buttons are clearly different kinds of products, it makes perfect sense to have different kinds of factories to generate the products. The utility of the abstract factory can be seen in the different kinds of concrete factories. As you will see, the concrete factories are only slightly different. Each must create an instance of all products classes (ProductA and ProductB in the example), but because the concrete classes are different they must create different concrete class instances. In this example, The GameFactory and BusinessFactory classes create different buttons and backgrounds and yet each is a child of the abstract factory class. The following listing shows the factory classes:

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

//Abstract Factory
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class AbFactory extends Sprite
	{
		public function createProductA(txt:String):ProductA
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		public function createProductB():ProductB
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
	}
}
 
//Game Factory
package
{
	public class GameFactory extends AbFactory
	{
		private var gameBtn:ProductA;
		private var gameWall:ProductB;
 
		override public function createProductA(txt:String):ProductA
		{
			gameBtn = new RoundBtn(txt);
			return gameBtn;
		}
 
		override public function createProductB():ProductB
		{
			gameWall=new GameStyle();
			return gameWall;
		}
	}
}
 
//Business Factory
package
{
	public class BusinessFactory extends AbFactory
	{
		private var businessBtn:ProductA;
		private var businessWall:ProductB;
 
		override public function createProductA(txt:String):ProductA
		{
			businessBtn = new RecBtn(txt);
			return businessBtn;
		}
 
		override public function createProductB():ProductB
		{
			businessWall=new BusinessStyle();
			return businessWall;
		}
	}
}

As you can see, each child factory returns its own unique set of buttons and background as shown in Figures 4 and 5 above.

The Abstract Products and their Children

The design pattern shows two abstract products, but you can think of them as at least two products. You can have as many products as you want, but for each abstract product, you need a concrete factory. To help keep everything clear, the abstract product classes were named ProductA and ProductB. The “A” products are buttons and the “B” products are backgrounds. As you can see in the following listings, each is different. Both include abstract methods, but ProductB has a heavily parameterized method, setWallName to add flexibility to the placement of a page header. To help keep everything clear, first you will see the abstract product and then the two concrete children classes for each.

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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152

//Product A: The buttons
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class ProductA extends Sprite
	{
		protected function setUpA(txt:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
	}
}
 
//Round Button concrete product
package
{
	import buttons.BtnStateEllipse;
 
	public class RoundBtn extends ProductA
	{
		private var btnStateEllipse:BtnStateEllipse;
 
		public function RoundBtn(txt:String)
		{
			setUpA(txt);
		}
 
		override protected function setUpA(txt:String):void
		{
			btnStateEllipse = new BtnStateEllipse(txt);
			addChild(btnStateEllipse);
		}
	}
}
 
//Rectangle button concrete product
package
{
	import buttons.BtnState;
 
	public class RecBtn extends ProductA
	{
		private var btnState:BtnState;
 
		public function RecBtn(txt:String)
		{
			setUpA(txt);
		}
 
		override protected function setUpA(txt:String):void
		{
			btnState = new BtnState(txt);
			addChild(btnState);
		}
	}
}
 
//Product B: The Backgrounds
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.text.TextFieldAutoSize;
 
	public class ProductB extends Sprite
	{
 
		protected function setWallName(wall:String,sz:int,hor:int,vert:int,txtField:TextField,format:TextFormat):void
		{
			txtField.text=wall;
			txtField.x=hor, txtField.y=vert;
			txtField.autoSize=TextFieldAutoSize.CENTER;
			format.size=sz;
			format.font="Arial Black";
			txtField.setTextFormat(format);
			addChild(txtField);
		}
 
		protected function setUpB():void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
	}
}
 
//Game Background
package
{
	import flash.display.Sprite;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.text.TextField;
	import flash.text.TextFormat;
 
	public class GameStyle extends ProductB
	{
		private var loader:Loader;
		private var url:URLRequest;
		private var txtField:TextField=new TextField();
		private var format:TextFormat=new TextFormat();
 
		public function GameStyle()
		{
			setUpB();
			setWallName("Game Time!",24,200,30,txtField,format);
		}
 
		override protected function setUpB():void
		{
			loader=new Loader();
			url=new URLRequest("GameStyle.swf");
			loader.load(url);
			addChild(loader);
		}
	}
}
 
//Business background
package
{
	import flash.display.Sprite;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.text.TextField;
	import flash.text.TextFormat;
 
	public class BusinessStyle extends ProductB
	{
		private var loader:Loader;
		private var url:URLRequest;
		private var txtField:TextField=new TextField();
		private var format:TextFormat=new TextFormat();
 
		public function BusinessStyle()
		{
			setUpB();
			setWallName("Serious Business",24,200,30,txtField,format);
		}
 
		override protected function setUpB():void
		{
			loader=new Loader();
			url=new URLRequest("BusinessStyle.swf");
			loader.load(url);
			addChild(loader);
		}
	}
}

By requesting the game products, the program returns both the rectangle shape buttons and the game background, and likewise with a request to the business products returns the business set. The separate concrete factories keep everything loose and the pattern has very few dependencies.

The Helpers

The RoundBtn class imports an ellipse button from the buttons package:

import buttons.BtnStateEllipse;

and the RecBtn class imports a rectangle button from the buttons package:

import buttons.BtnState;

So in creating the button scripts, the package indicates the buttons folder. The following scripts are found in the buttons folder. These helper classes are reusable just like the participants in a design pattern. However, because literals are used in these for the colors used with the button states, their flexibility is limited to the particular style and color scheme in the buttons.

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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115

//Button style for games
package buttons
{
    //Ellipse shape
	import flash.display.Sprite;
	import flash.display.Shape;
	import flash.text.TextFormat;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
 
	class BtnBaseOval extends Sprite
	{
		private var btnLabel:TextField;
		private var format:TextFormat;
		private var btnWidth:Number;
		private var bkground:Shape;
 
		public function BtnBaseOval (color:uint,color2:uint,btnLabelText:String)
		{
			btnLabel=new TextField();
			btnLabel.text=btnLabelText;
			btnLabel.x=5;
			btnLabel.textColor=0x24241c
			btnLabel.autoSize=TextFieldAutoSize.CENTER;
 
			format=new TextFormat("Arial Black");
			format.size=12;
			btnLabel.setTextFormat (format);
			btnWidth=90;
 
			bkground=new Shape;
			bkground.graphics.beginFill (color);
			bkground.graphics.lineStyle (.25,color2);
			bkground.graphics.drawEllipse (0,0,btnWidth,18);
 
			addChild (bkground);
			addChild (btnLabel);
		}
	}
}
 
//Button states and colors game buttons
package buttons
{
	import flash.display.SimpleButton;
 
	public class BtnStateEllipse extends SimpleButton
	{
		public function BtnStateEllipse (txt:String)
		{
			upState = new BtnBaseOval(0x698c3a, 0x218894,txt);
			downState = new BtnBaseOval(0xc7c68d,0x4d0005, txt);
			overState= new BtnBaseOval(0x48f23,0x218894,txt);
			hitTestState=upState;
		}
	}
}
 
//Button style for Business
package buttons
{
	//Set up rectangular shape
	import flash.display.Sprite;
	import flash.display.Shape;
	import flash.text.TextFormat;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
 
	class BtnBaseRec extends Sprite
	{
		private var btnLabel:TextField;
		private var format:TextFormat;
		private var btnWidth:Number;
		private var bkground:Shape;
 
		public function BtnBaseRec (color:uint,color2:uint,btnLabelText:String)
		{
			btnLabel=new TextField() ;
			btnLabel.text=btnLabelText;
			btnLabel.x=5;
			btnLabel.textColor=0x24241c;
			btnLabel.autoSize=TextFieldAutoSize.LEFT;
 
			format=new TextFormat("Verdana");
			format.size=12;
			btnLabel.setTextFormat (format);
			btnWidth=90;
 
			bkground=new Shape;
			bkground.graphics.beginFill (color);
			bkground.graphics.lineStyle (.25,color2);
			bkground.graphics.drawRect (0,0,btnWidth,18);
 
			addChild (bkground);
			addChild (btnLabel);
		}
	}
}
 
//Button states and colors business buttons
package buttons
{
	import flash.display.SimpleButton;
 
	public class BtnState extends SimpleButton
	{
		public function BtnState (txt:String)
		{
			upState = new BtnBaseRec(0xa9b890, 0x24241c,txt);
			downState = new BtnBaseRec(0xffff7f8,0xcd1722, txt);
			overState= new BtnBaseRec (0xcd1722,0xa9b890,txt);
			hitTestState=upState;
		}
	}
}

In looking back over this example, keep in mind that these last set of classes, the helper classes, are not part of the pattern itself. Rather, they are used to make it easy to create buttons without resorting to either the button symbols made in Flash or Flex. However, if you’d prefer the factories to use the built-in button components rather than those in the helper classes, you will find it easy to do so. Just change the targets of creation in the concrete product classes where the buttons are assigned.

When to Use the Abstract Factory

The key element in the Abstract Factory Design Pattern is the idea of families of related dependent objects. After working with the pattern for a very short time, it offered up many solutions in my mind. None of us work with single programs—single projects at one time, certainly—but these projects are hardly single programs. They do indeed have certain parts that go together in one context but not another. So instead of having to work up an entire new program to work with families of these objects, this pattern allows you the convenience of working with one group or another depending on the project’s needs.

Note: Chandima wrote the chapter in our book on the Factory Method, and he gave me invaluable help on the main program in this post as well.

Recap

Up to this point we’ve examined a simple program that loads external text and graphics, a common ActionScript chore. In the most general terms, this is where we’ve been:

• Part I: Identifying the problem in a current solution. Why ActionScript on the Timeline can cause problems.
• Part II: Providing a simple OOP solution: Use of Inheritance
• Part III: Loosening Up a programs structure: Adding a design pattern element —a simple factory

To conclude the process, we now come to the last part—introducing an actual design pattern to the work place.

• Part IV: Establishing a Design Pattern Foundation.

Given the preceding steps, the context is now in place to add a full design pattern.

From Part to Whole

Part III introduced the Simple Factory method inserted into an existing OOP program. Now it’s time to step back and look at a design pattern en toto and instead of incrementally adding to the existing program, we will refactor the whole kit-n-kaboodle from the perspective of a design pattern.

To get started, if you’re not familiar with the Factory Method pattern, take a look at Chapter 2. In fact Chandima’s Sprite Factory example beginning on page 84 is one of the clearest and most appropriate examples that you can find of the Factory Method pattern in ActionScript 3.0. So before continuing, you might want to do a quick review of the Factory Method and take a look at Figure 1, the class diagram for the pattern. (We’ll wait for you…).

Figure 1: Factory Method Design Pattern

As you can see, the Factory Method (simple factory) is part of the Creator interface and the ConcreteCreator. The interface is an abstract class; so at least one of the methods needs to be abstract—impossible to directly instantiate but easily overridden in a child class.

The Product class is an abstract version of what we called the Staff class in the previous version of the application. Again, using an abstract class requires abstract methods to be overridden in the child classes. The ConcreteProduct classes were previously the Designer, Developer and HCI classes. We can keep the old designations for clarity, but their parent class is now the Product interface (abstract class). That means that the child classes can now make adjustments to the methods using the override statement. However, those methods not overridden do not need to be revised at all. Figure 2 shows the design pattern (without the pseudo-code blocks.) and with the actual child classes for the Product abstract class.

Figure 2: Factory Method Pattern applied to current project

As a reminder, the dashed lines with the arrows means that origin of the dashed line creates an instance of the class to which the arrowhead points.

One Day They Came to Work and Found All These Design Patterns

In the process of creating this series of posts and working on a presentation for the Atlanta group with similar aims, I’ve been able to review the process of introducing design patterns at work. My conclusion is that we need to step both gently and firmly, and by all means do so in a practical way. (When the choice is between being on time and being right, take on time.) However, OOP and design patterns need to be at the back of your mind so that you can begin viewing projects in terms of OOP and design patterns. In turn, this will make your company’s products better, more flexible and less likely to choke up at the wrong time. (They never choke up at the right time—whenever that is.)

So, in looking at this refactored program, keep in mind that we started with a simple program embedded in the Timeline using keyframes to choose graphic and text images. Also, keep in mind the problem, and how the design pattern became a solution for that problem.

The Client Looks the Same

We’ll start with the Client, and not surprisingly, it is little changed from last time. However, the request is typed to an abstract class this time (factory:Creator).

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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	//Client Class
 
	public class Client extends Sprite
	{
		private var logo:Sprite = new Logo();
		private var splash:Sprite = new Splash();
		private var desBtn:Button = new Button();
		private var devBtn:Button = new Button();
		private var hciBtn:Button = new Button();
		private var staffNow:String;
		private var staffDisplay:Sprite;
		private var staff:String;
		private var factory:Creator=new ConcreteCreator();
 
		public function Client()
		{
			desBtn.label = "Designer";
			desBtn.addEventListener(MouseEvent.CLICK,selectStaff);
			addChild(desBtn);
			desBtn.x = 424,desBtn.y = 66;
 
			devBtn.label = "Developer";
			devBtn.addEventListener(MouseEvent.CLICK,selectStaff);
			addChild(devBtn);
			devBtn.x = 424,devBtn.y = 116;
 
			hciBtn.label = "HCI";
			hciBtn.addEventListener(MouseEvent.CLICK,selectStaff);
			addChild(hciBtn);
			hciBtn.x = 424,hciBtn.y = 166;
 
			logo.x = 16,logo.y = 16;
			logo.width = 150,logo.height = 121.5;
			addChild(logo);
 
			splash.x = 32,splash.y = 168;
			addChild(splash);
		}
 
		private function selectStaff(e:MouseEvent)
		{
			staff = e.target.label.toLowerCase();
			splash.visible=false;
 
			if (staffDisplay)
			{
				removeChild( staffDisplay );
			}
 
			staffDisplay = factory.makeStaff(staff);
			addChild( staffDisplay );
		}
	}
}

This next class, the Creator, is an abstract one. The functionality of this class is not appreciated in this particular application because we derive only a single child from it. However, if we wanted to change the program to create other elements that we may wish, such as a button factory we could do so relatively easily, and because of the loose linkage, adding another child will not disrupt the overall program.

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

package
{
	//Asbstract class
	//Creator
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var staffNow:Sprite;
 
		public function makeStaff(staff:String):Sprite
		{
			staffNow = createStaff(staff);
			return staffNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function createStaff(staff:String):Sprite
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

The Creator provides the abstract method for the factory in the Factory Method design pattern. The ConcreteCreator is where the actual factory work is accomplished.

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

package
{
	//Factory
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class ConcreteCreator extends Creator
	{
		override protected function createStaff(staff:String):Sprite
		{
			switch (staff)
			{
				case "designer" :
					return ( new Designer() );
					break;
				case "developer" :
					return ( new Developer() );
					break;
				case "hci" :
					return ( new HCI() );
					break;
				default :
					throw new Error("Invalid type of staff specified");
					return null;
			}
		}
	}
}

As you can see, that’s almost identical to the Factory class in Part III of this series of posts. The createStaff() method is overridden. Because it is a child of the Creator class, it has the makeStaff() method, and it uses the creatStaff() method in any way that it has been overridden in the concrete creator itself.

The Product and Its Children

A second abstract class, Product, as noted above, is very similar to the Staff class introduced in Part II of this series. The difference is that the Staff class was concrete and the Product class is abstract. Two of its methods are abstract, and both need to be overridden and detailed in the child classes. So instead of inheritance to a concrete class with no flexibility, the child classes of the Product can customize the overridden functions. The following shows how the Product class is set up:

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

package
{
	import flash.errors.IllegalOperationError;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFieldType;
	import flash.events.Event;
	import flash.text.TextFormat;
 
	//Abstract class
	public class Product extends Sprite
	{
		private var loadCheck:URLLoader;
		private var txtFld:TextField = new TextField();
		private var textFormat:TextFormat = new TextFormat();
		private const WIDE:int=200;
		private const TEXTCOLOR:uint=0x007700;
 
		protected function loadInfo(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function nowLoaded(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial Black";
			textFormat.size = 16;
			txtFld.type = TextFieldType.DYNAMIC;
			txtFld.width = WIDE;
			txtFld.wordWrap = true;
			txtFld.textColor =TEXTCOLOR;
			txtFld.defaultTextFormat = textFormat;
			txtFld.text = loadCheck.data;
			addChild(txtFld);
			txtFld.x = 180,txtFld.y = 331;
		}
 
		protected function loadImg(img:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
 
		}
	}
}

The Product has two abstract and one concrete methods. The thinking is that the onLoaded() operation is not going to change, but is needed to have everything laid out for the incoming Sprite object containing the image and text. However, we might come up with positioning ideas for the image that we can change. As for the abstract method for adding the text, it’s probably not going to change, but if it does, we can make the changes in the child classes. If we want to re-position the text, we can still use the concrete method in the Product class itself to change all text.

The result of having abstract methods is that they need to be filled out (populated by code) in the child classes. As a consequence, the concrete Product classes (Designer, Developer, and HCI) are all larger than the tiny ones in previous posts in this series. They have to override the abstract methods and add the code they want. In this example, they’re virtually identical to one another, but if we wanted to change one, we could do so without interfering with the other concrete child Product classes. The following three classes show how the concrete products are created:

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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143

//Designer
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class Designer extends Product
	{
		private var staffText:String;
		private var staffImg:String;
		private var url:URLRequest
		private var loader:Loader
		private var fileNow:URLRequest;
		private var txtLoader:URLLoader;
		private var loadCheck:URLLoader;
 
		public function Designer()
		{
			staffText = "text/designer.txt";
			staffImg = "images/designer.png";
 
			loadInfo(staffText);
			loadImg(staffImg);
		}
 
		override protected function loadInfo(txtInfo:String):void
		{
			txtLoader = new URLLoader();
			txtLoader.addEventListener(Event.COMPLETE,nowLoaded);
			fileNow = new URLRequest(txtInfo);
			txtLoader.load(fileNow);
		}
 
		override protected function loadImg(staffImg:String):void
		{
			url = new URLRequest(staffImg);
			loader=new Loader();
			loader.load(url);
			addChild(loader);
			loader.x = 180,loader.y = 131;
		}
	}
}
 
//Developer
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class Developer extends Product
	{
		private var staffText:String;
		private var staffImg:String;
		private var url:URLRequest
		private var loader:Loader
		private var fileNow:URLRequest;
		private var txtLoader:URLLoader;
		private var loadCheck:URLLoader;
 
		public function Developer()
		{
			staffText = "text/developer.txt";
			staffImg = "images/developer.png";
 
			loadInfo(staffText);
			loadImg(staffImg);
		}
 
		override protected function loadInfo(txtInfo:String):void
		{
			txtLoader = new URLLoader();
			txtLoader.addEventListener(Event.COMPLETE,nowLoaded);
			fileNow = new URLRequest(txtInfo);
			txtLoader.load(fileNow);
		}
 
		override protected function loadImg(staffImg:String):void
		{
			url = new URLRequest(staffImg);
			loader=new Loader();
			loader.load(url);
			addChild(loader);
			loader.x = 180,loader.y = 131;
		}
	}
}
 
//HCI
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class HCI extends Product
	{
		private var staffText:String;
		private var staffImg:String;
		private var url:URLRequest
		private var loader:Loader
		private var fileNow:URLRequest;
		private var txtLoader:URLLoader;
		private var loadCheck:URLLoader;
 
		public function HCI()
		{
			staffText = "text/hci.txt";
			staffImg = "images/hci.png";
 
			loadInfo(staffText);
			loadImg(staffImg);
		}
 
		override protected function loadInfo(txtInfo:String):void
		{
			txtLoader = new URLLoader();
			txtLoader.addEventListener(Event.COMPLETE,nowLoaded);
			fileNow = new URLRequest(txtInfo);
			txtLoader.load(fileNow);
		}
 
		override protected function loadImg(staffImg:String):void
		{
			url = new URLRequest(staffImg);
			loader=new Loader();
			loader.load(url);
			addChild(loader);
			loader.x = 180,loader.y = 131;
		}
	}
}

This ends the classes that make up the Factory Method pattern used in this post. They’re available to download. Just click the Download button below and load ‘em up in either Flash Builder or Flash.

Back to Work

As this New Year begins with new problems and opportunities for solving problems, we really need to think about the quality of our work. Down the line somewhere, a program that you helped write with good OOP and design pattern practices may solve someone else’s problem. The program may have one feature that because of what you did made it better. Maybe if we just do a little better for ourselves in terms of program practices, something good will come of it. Then at this time next year, we’ll all be a little better. For me, that’s enough.