Bringing together Abstract Factories and Families of Products

In the last installment of the saturated Abstract Factory, you saw that unlike the Factory Method where a concrete factory instantiates a single concrete product, the Abstract Factory instantiates a family of products. In this final post in the Abstract Factory saturation series, you will see how the factories (creational classes) create more than a single product. Each of the concrete creational classes instantiate two or more concrete products that have different product interfaces but are “joined in instantiation” by the individual concrete factories that share a common interface. In effect, the family planning is done by the Abstract Factory interface, and not the Product interface. Click the factory button to play the final product of this series and the download button to get all of the files we’ll be looking at:

Before continuing take another look at the full class diagram of the Abstract Factory design pattern in Figure 1:

Figure 1: Abstract Factory Class Diagram

First, consider the way that the Abstract Factory interface contains methods for instantiating more than a single product. Each concrete factory instantiates a minimum of two products. It is like the Factory Method, but each concrete factory only instantiates a single product in the Factory Method. The Abstract Factory creates Multiple products.

Figure 2: Think of Ganesha when considering the role of the busy Client

Gathering the Files

In order to work with a full scale (yet modest) Abstract Factory design pattern, I found that it helps to look at the files that are part of the pattern in a class diagram. Figure 3 shows the classes and interfaces to be used.

Figure 3:Abstract Factory File Diagram

The Product Families

Continuing from previous posts in this series, the product families are made up of a “rounded” family and a “blocky” family. Each family consists of graphic (IProduct) and text (ITextProd) interfaces and their accompanying concrete implementations. The following listings has both interfaces and all of the concrete 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
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

//Interface for graphic product
package
{
	import flash.display.Shape;
 
	public interface IProduct
 
	{
		function productSpecs(clr:uint,stroke:uint):Shape;
	}
}
 
//Curvey implementation
package
{
	import flash.display.Shape;
 
	public class CircleProduct implements IProduct
	{
		private var perfectCircle:Shape=new Shape  ;
 
		public function productSpecs(clr:uint,stroke:uint):Shape
		{
			perfectCircle.graphics.beginFill(clr);
			perfectCircle.graphics.lineStyle(stroke,0xF6E497);
			perfectCircle.graphics.drawEllipse(0,0,150,150);
			perfectCircle.graphics.endFill();
			return perfectCircle;
		}
	}
}
 
//Blocky implementation
package
{
	import flash.display.Shape;
 
	public class BlockProduct implements IProduct
	{
		private var perfectBlock:Shape=new Shape();
 
		public function productSpecs(clr:uint,stroke:uint):Shape
		{
			perfectBlock.graphics.beginFill(clr);
			perfectBlock.graphics.lineStyle(stroke, 0xB9121B);
			perfectBlock.graphics.drawRect(0, 0, 150, 150);
			perfectBlock.graphics.endFill();
			return perfectBlock;
		}
	}
}
 
//Interface for Text element
package
{
	import flash.text.TextField;
 
	public interface ITextProd
	{
		function doGraphicText(clr:uint,fsize:uint,msg:String):TextField;
	}
}
 
//Curvey Text
package
{
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.text.TextFieldAutoSize;
 
	public class CirText implements ITextProd
	{
		private var txtFld:TextField=new TextField();
		private var txtFormat:TextFormat=new TextFormat();
 
		public function doGraphicText(clr:uint,fsize:uint,msg:String):TextField
		{
			txtFld.autoSize = TextFieldAutoSize.LEFT;
			txtFormat.font = "Comic Sans MS";
                        txtFormat.color = clr;
                        txtFormat.size = fsize;
			txtFld.defaultTextFormat = txtFormat;
			txtFld.text=msg;
			return txtFld;
		}
	}
}
 
//Blocky Text
package
{
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.text.TextFieldAutoSize;
 
	public class BlockText implements ITextProd
	{
		private var txtFld:TextField=new TextField();
		private var txtFormat:TextFormat=new TextFormat();
 
		public function doGraphicText(clr:uint,fsize:uint,msg:String):TextField
		{
			txtFld.autoSize = TextFieldAutoSize.LEFT;
			txtFormat.font = "Arial Black";
                        txtFormat.color = clr;
                        txtFormat.size = fsize;
			txtFld.defaultTextFormat = txtFormat;
			txtFld.text=msg;
			return txtFld;
		}
	}
}

As you can see, nothing much has changed in the products other than some of the colors in the strokes. The family of the products remain constant.

The Factories

The factories have changed in important ways. Instead of returning TextField and Shape objects, they return the concrete products typed through their interfaces. This change is important because they Client holds references to the product interfaces and not the concrete returns from the classes. So with this arrangement, the Client can request a whole product from the factory and not just the returns. The following three objects make up the Abstract Factory interface and 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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

//Abstract Factory
package
{
	public interface IAbfactory
	{
		function createGraphic():IProduct;
		function createText():ITextProd;
	}
}
 
//Factory implementation that instantiates the "Round Family" of products
package
{
	public class RoundFactory implements IAbfactory
	{
		private var grProd:IProduct;
		private var txtProd:ITextProd;
 
		public function createGraphic():IProduct
		{
			grProd=new CircleProduct();
			return grProd;
		}
 
		public function createText():ITextProd
		{
			txtProd=new CirText();
			return txtProd;
		}
	}
}
 
//Factory implementation that instantiates the "Blocky Family" of products
package
{
	public class BlockFactory implements IAbfactory
	{
		private var grProd:IProduct;
		private var txtProd:ITextProd;
 
		public function createGraphic():IProduct
		{
			grProd=new BlockProduct();
			return grProd;
		}
 
		public function createText():ITextProd
		{
			txtProd=new BlockText();
			return txtProd;
		}
	}
}

Notice that all of the returns from the two concrete factory classes are interfaces and not concrete products. When it comes time to make changes, the loosely bound objects won’t complain where the alternations follow the interfaces but are different from the concrete implementations.

The Big Time Client

The humble client is an integral part of the Abstract Factory design pattern. It holds a reference to all of the interfaces in the design. In setting up the Client class I had to (seriously) tinker with the factory classes. I wanted to hold a reference to the product interfaces in the classes, and so I wanted the factories to return objects typed as interfaces rather than tightly bind them to concrete classes.

None of the concrete implementations of the product classes have constructor methods; and so when a concrete product typed to the interface in the Client is instantiated by the factories, there are no surprises. To get something concrete from the products I was able to use the Client objects’s methods that held a reference to the product interfaces. The following listing shows the Client class with a minimum UI:

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

//The Mighty Client
package
{
	import flash.display.Sprite;
	import flash.display.Shape;
	import flash.text.TextField;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		//Client ref to Abstract Factory
		private var prodFamily:IAbfactory;
 
		//Client ref to Abstract Products
		private var cirProduct:IProduct;
		private var cirText:ITextProd;
		private var blockProduct:IProduct;
		private var blockText:ITextProd;
 
		private var holder:Sprite=new Sprite();
		private var txtstore:Sprite=new Sprite();
		private var tempGr:Shape;
		private var tempTxt:TextField;
 
		//UI
		private var btnRnd:Button=new Button();
		private var btnBlock:Button=new Button();
 
		public function Client()
		{
			addUI();
		}
 
		private function curvey(e:MouseEvent):void
		{
			if (tempGr)
			{
				holder.removeChild(tempGr);
				txtstore.removeChild(tempTxt);
			}
 
			prodFamily=new RoundFactory();
 
			cirProduct=prodFamily.createGraphic();
			cirText=prodFamily.createText();
 
			holder.x=100,holder.y=100;
			tempGr=cirProduct.productSpecs(0xb9121b,8);
			holder.addChild(tempGr);
			addChild(holder);
 
			txtstore.x=holder.x+5,txtstore.y=holder.y+50;
			tempTxt=cirText.doGraphicText(0xF6E497,18,"Abstract Curve");
			txtstore.addChild(tempTxt);
			addChild(txtstore);
		}
 
		private function blocky(e:MouseEvent):void
		{
			if (tempGr)
			{
				holder.removeChild(tempGr);
				txtstore.removeChild(tempTxt);
			}
 
			prodFamily=new BlockFactory();
 
			blockProduct=prodFamily.createGraphic();
			blockText=prodFamily.createText();
 
			holder.x=100,holder.y=100;
			tempGr=blockProduct.productSpecs(0xF6E497,8);
			holder.addChild(tempGr);
			addChild(holder);
 
			txtstore.x=holder.x+5,txtstore.y=holder.y+50;
			tempTxt=blockText.doGraphicText(0xb9121b,16,"Abstract Block");
			txtstore.addChild(tempTxt);
			addChild(txtstore);
		}
 
		private function addUI():void
		{
			//UI
			btnRnd.addEventListener(MouseEvent.CLICK,curvey);
			btnRnd.label="Curves";
			btnRnd.x=10,btnRnd.y=10;
			addChild(btnRnd);
			btnBlock.addEventListener(MouseEvent.CLICK,blocky);
			btnBlock.label="Blocks";
			btnBlock.x=10,btnBlock.y=40;
			addChild(btnBlock);
		}
	}
}

That about fills out our agenda on the Abstract Factory. As mentioned at one point, this design gave me the heebie-jeebies, but after wrestling it to the ground (again) I like it more and more. The key to understanding the pattern and successfully using this pattern lie in the following elements:

• Think of products as Familes of Products
• A Concrete Factory for Each Product Family
• The Client only references Interfaces (including abstract classes.)
• Return product objects to the Client; not product results

If you focus of those three features, I think you’ll find it to be much easier to use and understand.

Some Afterthoughts

I spent a lot of time with the Gang of Four’s book, and one thing that struck me was the fact that the very first design pattern presented after the introductory materials is the Abstract Factory. Imagine some poor soul who wants to learn design patterns and decides that the wisest course of action is to start at the beginning and work his way through sequentially. The image that follows is the guy curled up in a corner with his thumb in his mouth shaking uncontrollably. While the first two chapters provide a logical sequence and the general grouping of the patterns into Creational, Structural and Behavioral makes sense, everything else is alphabetical. Just a newbie’s luck that the first pattern is a bit challenging. The Adapter or Template Method patterns are much gentler beginnings.

While adding new families of products is pretty simple using the Abstract Factory, adding new products themselves is not. In the example in this post, the families are made up of a “round” and “block” styles that rely on images and text. To add a “futuristic” style that includes an image and text would be pretty easy. However, if we want to extend a product family to another element, the Abstract Factory takes some tinkering. That’s because the Abstract Factory sets the products that can be included–ours had the IProduct and ITextProd. Adding another product such as a UI would require changing the Abstract Factory and all of it’s child classes.

I don’t see it as difficult as GoF make it out to be. Most of the coding is in the products, and while adding another product to the factories involves some effort, it’s not a whole lot. More importantly, you just have to tweak the factories and not have to touch the products. Further, the new products won’t get in the way of the old ones.

Sooner or later, Flash and Flash Builder need to be part of the smart phone mix. Several have been working on Android and even a few have been able to use ActionScript 3.0 with iPhone/iPad apps. If ever there were multiple families of products it’s in the arena of small mobile apps and ones that present well on monitor screens approaching the size of drive-in theaters. The Abstract Factory seems like an ideal tool for making apps that fill the bill for different “families” of products—small mobile, tablet-size, laptop and fill-the-wall screens.

Favor Composition over Inheritance

Inheritance in OOP

Ever since The Gang of Four put forth the pithy dictum,

Favor object composition over class inheritance,

OOP programmers have decidedly shifted in the direction of creating programs using composition more than inheritance. Further, any inheritance is fairly shallow with an abstract class as a parent that doubles as an interface.

However, inheritance is a core concept in OOP, and it’s not something that should be dismissed lightly. Further, in going through the design pattern catalog that Gamma et al have compiled, you will see a lot of inheritance in the class diagrams. Lest we not throw out something useful, let’s look at a simple example of using inheritance. (You may want to download the files and look at the static outcome first using the buttons below.)

The Architect

Suppose I want to create an architect program that I can use to create different shapes. In fiddling around I create a class with Sprite and Shape properties along with a method that builds and returns a rectangle. In order not to embarrass myself too much, I make an effort to use a decent color scheme; so I visit kuler.adobe.com and select a color pattern named moderne interieur. I then create a base class I name Architect shown in the following listing:

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

package
{
	//Colors: F5F4E1,D6C9B5,B4AA97,D44917,82877A
	import flash.display.Sprite;
	import flash.display.Shape;
 
	public class Architect extends Sprite
	{
		protected var foundation:Sprite=new Sprite();
		protected var archGraphic:Shape=new Shape();
 
		public function buildBox(ex:Number,wy:Number,
		          len:Number,hi:Number,
		          fill:Number):Sprite
		{
			archGraphic.graphics.beginFill(fill);
			archGraphic.graphics.lineStyle(2,0x82877A);
			archGraphic.graphics.drawRect(ex, wy, len, hi);
			archGraphic.graphics.endFill();
			foundation.addChild(archGraphic);
                        return foundation;
		}
	}
}

Anticipating that I may want to extend the class, I made the main properties protected so that any child classes can inherit them and preserve as much encapsulation as possible. However, the rectangle-building method must be public so that it can be used by clients outside the class. Further the line around the rectangle is hard-coded to a given width and color, but otherwise, it’s fairly flexible. All of the other dimensions of my rectangle are entered through a parameter. Finally, the image is stuffed into a Sprite object and then returned.

Extending the Architect

An architect does not live by rectangles alone; so we’ll add an ellipse. However, instead of starting from scratch or adding more methods, as OOP programmers, we can just extend the Architect to a child class that includes a method to create ellipses. The best part is that if we extend the Architect class, we’ll also get the Sprite properties because Architect extended Sprite and we’ll inherit the protected properties as well as the method for making rectangles.

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

package
{
	//Colors: F5F4E1,D6C9B5,B4AA97,D44917,82877A
	import flash.display.Sprite;
	import flash.display.Shape;
 
	public class ArchEllipse extends Architect
	{
		public function buildEllipse(ex:Number,wy:Number,
		          len:Number,hi:Number,
		          fill:Number):Sprite
		{
			archGraphic.graphics.beginFill(fill);
			archGraphic.graphics.lineStyle(2,0x82877A);
			archGraphic.graphics.drawEllipse(ex, wy, len, hi);
			archGraphic.graphics.endFill();
			foundation.addChild(archGraphic);
			return foundation;
		}
	}
}

Now, my child class, ArchEllipse, can do everything the parent class does and, in addition, create ellipses. All I had to do was to extend the parent and add a single method. The buildEllipse() method is able to use the same parameters as the buildBox() method in the Architect class. That was so easy, that I decided to extend the ArchEllipse to add a class to build triangles; so the next class simply extends ArchEllipse as the following shows:

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

package
{
	//Colors: F5F4E1,D6C9B5,B4AA97,D44917,82877A
	import flash.display.Sprite;
	import flash.display.Shape;
 
	public class ArchTriangle extends ArchEllipse
	{
		public function buildTriangle(fill:uint,
		         startX:Number,startY:Number,
		         nextX:Number,nextY:Number,
		         lastX:Number,lastY:Number):Sprite
		{
			archGraphic.graphics.beginFill(fill);
			archGraphic.graphics.drawTriangles(Vector.<number>([ startX,startY,  nextX,nextY,  lastX,lastY]));
			archGraphic.graphics.endFill();
			foundation.addChild(archGraphic);
			return foundation;
		}
	}
}

Now, the class, ArchTriangle, can do everything its parent classes can do, plus it can create triangles. To test the class, instead of adding yet another child class with a constructor function, we can just make a Client class to request it.

The Client

With a simple client class, all that’s required is to instantiate a single instance of the ArchTriangle, and then invoke all of the methods it has plus two inherited from its parent classes. The following shows the Client code:

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

package
{
	//Colors: F5F4E1,D6C9B5,B4AA97,D44917,82877A
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var arch:ArchTriangle=new ArchTriangle();
 
		public function Client()
		{
			addChild(arch.buildBox(50,50,400,300,0xD44917));
			addChild(arch.buildEllipse(75,100,100,60,0xF5F4E1));
			addChild(arch.buildTriangle(0xD6C9B5,200,100,300,100,200,300));
		}
	}
}

If I put everything into a class diagram, I can see that the Client looks like it’s dealing off the bottom on the deck; however, it’s just instantiating the child class that has all the goodies. Figure 1 shows the class diagram, and you can see that it uses nothing but concrete classes:

Figure 1: Concrete Inheritance

Clearly, in its current form, the program is not too useful. However, all you’d have to do is to change the Client so that it includes some kind of input and buttons to add any shape in any color, size and location you want. You can use components from either Flash Builder 4 (Flex) or Flash Professional in the client to make it easy.

Make a Dynamic Client with User Input

Go ahead and create a Client that will turn this into an architect program that you can use to design a house—or just rearrange the furniture in your apartment. All you need is an input box for the different parameters in the different objects. (The same input can be used for the boxes and ellipses.) See how easy it is.

Also, while you’re at it, why not extend the ArchTriangle class with a ArchRounded class to make rounded rectangles with fill gradations. This would give you experience with using inheritance and seeing if this kind of OOP programming that can be sustained. Send in your creation in the comments section and we’ll put it up for illustrating creative roles for the client.

In the next installment, we’ll see about doing the same thing with components.

This is the First in the Abstract Factory Saturation Series

To understand the Abstract Factory design pattern, we need to begin by understanding the whole category of Creational Patterns and what the Gang of Four means by creation. On pages 63-64 of our book and pages 81-85 of GoF, you will find more details about creational patterns, and here I’d like to just touch on some of the key points. Also, Chapter 2 of our book, is an excellent chapter (written by Chandima) on the Factory Method Pattern that introduces the whole concept of factory. And of course you may want to look at our original post on the Abstract Factory design pattern.

When You Depend on Object Composition

One of the first and recurrent principles of design patterns is to favor composition over inheritance. As your programs come to depend more on object composition, you need to think more about creating components required for a task. To a large extent, the creational patterns are designed for composing. GoF note that as the emphasis shifts from inheritance towards composition, other changes occur.

…emphasis shifts away from hard-coding a fixed set of behaviors towards defining a smaller set of fundamental behaviors that can be composed into any number of more complex ones. Thus creating objects with particular behaviors requires more than simply instantiating a class. pg. 81

The result of this shift can be found in two recurring themes in creational patterns:

• Creational patterns encapsulate knowledge about which concrete classes the system uses.
• Creational patterns hide how instances of these classes are created and put together.

If loose coupling is the overriding theme of design patterns; then creational patterns show us how to create loosely coupled objects and use them in a composition rich application.

An Overview of the Abstract Factory

In our first Saturated series installment, we examined how the Strategy pattern encapsulated families of algorithms. The Abstract Factory provides

…an interface for creating families of related or dependent objects without specifying their concrete classes.(p.87).

To see how this is done, we’ll start with a class diagram and a discussion of the pattern participants. Figure 1 shows the class diagram:

Figure 1: Abstract Factory Class Diagram

Getting a Handle on the Abstract Factory

To best understand the Abstract Factory we need to break it down and examine each of its participants.

1. AbstractFactory: This is an interface that holds operations that create abstract product objects. This is where the concept of abstract factory comes from. The concrete factories that actually create the product object implement this interface.
2. ConcreteFactory: The factories implement the operations to create concrete product objects. By creating the products used by the Client, these factories maintain loose coupling between the Client and the Product.
3. AbstractProduct: Most design patterns have single interfaces for different part of the the pattern. However, the Abstract Factor design pattern has multiple interfaces for the products. This is where the composition takes place as the concrete factories implement multiple products for the Client.
4. ConcreteProduct: Each product is an implementation of an interface (AbstractProduct) that structures the product type.
5. Client: Makes all requests only through the abstract interfaces. Here you will find good examples of programming to an interface instead of an implementation.

Now in looking at the class diagram in Figure1, we can see a little more clearly what role each participant plays. However, in the next installment of the Abstract Factory, I’d like to back off a bit and examine exactly what it means to create a composed object. We’ll take a simple example of composition and then see how a factory can create an instance of the composed object for use by a Client. In the meantime, take a look at our first post on the Abstract Factory to provide a context for the rest of this series.

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.