ActionScript 3.0 Design Patterns

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

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

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

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