Archive for the 'Factory Method' Category

ActionScript 3.0 Lazy Initialization and the Factory Method Design Pattern

Published on May 24, 2010 in Factory Method and Lazy Initialization. by William B. Sanders 8 Comments
Lazy Initialization

Lazy Initialization

The other day I was re-reading Chandima’s description of key OOP concepts used in the Factory Method design pattern. It is beautifully encapsulated in a little over a half a page (page 84). The Factory Method allows you to separate the creation of objects from their use. It says a bit more, but it is a nice piece in both describing a design pattern principle and explaining what the Factory Method does. This led to re-reading the Factory Method chapter in Design Patterns: Elements of Reusable Object-Oriented Software—the Gang of Four’s book. Normally, I just go over the main points, but I came across a little passage that read:

Just be careful not to call factory methods in the Creator’s constructor—the factory method in the ConcreteCreator won’t be available yet. (page 112)

The comment was directed at some issues in C++ which may or may not have any bearing on ActionScript 3.0, but just in case it did, I continued reading. The point being made was you can avoid these problems by accessing products only through accessor operations that create products on demand. So what are accessor operations? Generally these are public methods that you can call to initiate creation of a product.

Time Out! Before we get too far ahead of ourselves, you can download all of the .as files for the Factory Method example by clicking the following button:
kilroy

The example is a simple one that creates three different shapes—ellipse, rectangle and triangle. Figure 1 shows how the Client arranged them to display a house in front a a pond with a cloud overhead:

<em><strong>Figure 1:</strong>Triangle, Ellipse and Rectangle Products</em>

Figure 1:Triangle, Ellipse and Rectangle Products

The program uses concrete creators to fetch shapes. The Client makes requests that size, color, and position the shapes.

Don’t Enslave Your Constructor Functions

This issue of the constructor functions reminded me of a post by Miško Hevery, the guy at Google who helps set Google’s programming standards. One of the key flaws in a program is where the constructor does real work. Besides violating the single responsibility rule, Miško goes on to explain the tell-tale signs that one has used his constructor function with outrageous disregard for both agile programming and loose coupling. As a result of reading Hevery’s work, a year or so ago, I began to seriously gear back on using a class’ constructor function; primarily by not including one in most of my classes. (My Client class is a glaring exception to the rule.) I’d usually have just the properties and operations (methods, functions) that I needed. The properties would initialize themselves—sort of. They’d be given an ID and then typed and that was all. The child classes could then use them in operations. Whenever I needed something, the Client would type a request to the interface (including abstract classes) and then make a request through concrete method in an operation. With the Factory Method, I make requests to the ConcreteCreator through the abstract Creator class.

In returning to GoF, they point out,

Instead of creating the concrete product in the constructor, the constructor merely initializes it to 0. (Page 112)

In this discussion, they note that Factory methods in C++ are always virtual functions. WTF?! (What’s That Function?!) Simply stated, any function that can be overridden in the child classes is a virtual one. Well, we can do that in ActionScript 3.0. In fact, that’s what we do in creating Abstract classes. (Why we can override and yet not have real Abstract classes is still a mystery to me.)

Continue reading ‘ActionScript 3.0 Lazy Initialization and the Factory Method Design Pattern’

ActionScript 3.0 Design Pattern Re-use and Modification

Published on December 23, 2009 in Design Patterns at Work and Factory Method. by William B. Sanders 0 Comments
Take This One to Work

Take This One to Work

Every Monday I have to separate out the paper, glass, aluminum, and plastic to recycle and take them up to the curb. This last Monday while engaged in this weekly ritual, I thought that recycling a design pattern might be an interesting exercise. Additionally, it’s the kind of design pattern advantage that can be used at work to save re-inventing the wheel when you have a similar development task. You may remember the Dragon Factory where we employed a Factory Method to set up an easy-to-use drag application. In the original Dragon Factory, both the Creator and Product participants had subclasses. However, with only a slight revision, it’s possible to create a little game for making different faces subclassing only the Product interface (abstract class). Figure 1 shows the File-Class Diagram:

<em><strong>Figure 1:</strong> Factory Method with Single Concrete Creator</em>

Figure 1: Factory Method with Single Concrete Creator

You can see the design similarities between this application (MrFace) and the Dragon application. The main difference is that this one has a single concrete factory (FaceCreator) for all of the concrete products. The factory churns out all of the Product children and puts them into an array. The Client requests the array from the Creator and pulls out the elements with a loop. As you can see, they’re all draggable elements. Try out the embedded SWF file below to see how it works:

MrFace

The same Product (from the Dragon application) is re-used so it is unnecessary to revise it. However, instead of a video and a dynamically generated graphic, all of the graphics were put into the Library as Sprite classes. (To make a Sprite class just change the Base class to flash.display.Sprite.)
Continue reading ‘ActionScript 3.0 Design Pattern Re-use and Modification’

Hitchhiker’s Guide to ActionScript 3.0: The Dragon Factory—Part 2

Published on September 13, 2009 in Design Patterns at Work and Factory Method. by William B. Sanders 4 Comments
Take This One to Work

Take This One to Work

You will remember the initial query that launched this two-part post started with an inquiry into the possibility of dragging a Video while it was playing. In order to make the query more relevant to design patterns, this second part looks at the process for expanding the larger issue of dragging objects inside a Sprite. Whenever undertaking such a project, begin with the Variation Table (aka Magic Table) to find the possible variations. The wrong way to start developing a design pattern for a practical problem is to look at all of the different class diagrams and pick one that looks like it will fit your problem. Instead, always start by asking, what varies?
download
In this case, the “hitchhiker” to be dragged is the particular type of object in question. We saw how to drag a Video object, but what about other objects that need to hitchhike on a Sprite to be dragged? So, we’re talking about different objects—or put otherwise—object variation. The closest matching variation in the Magic Table is the variation of the subclass of the object that is instantiated. That means a Factory Method design. (See how easy that was?)
Continue reading ‘Hitchhiker’s Guide to ActionScript 3.0: The Dragon Factory—Part 2′

ActionScript 3.0 Design Pattern Catalog: Creational Patterns

Published on July 15, 2009 in Catalog, Factory Method and Tools. by William B. Sanders 2 Comments

A Tale of Two Factories: One New and One Reused

This is the first of three posts on the actual AIR ActionScript 3.0 Design Pattern catalog. Previously, I had discussed the thinking that went into the design of the Catalog, and here is the first actual AIR application with the Creational Patterns portion of the catalog all set up and ready to use. Figure 1 shows what each page looks like: (By the way, the actual image in the catalog is almost twice the size as what you see in Figure 1.)

catalog1
Figure 1: Design Pattern Catalog Page

Before going on, you can download all of the source code and the AIR application by clicking the Download button. Additionally, you may want to access the Catalog Online.

download

I changed the color combinations. I concluded that Kuler’s 1944mustang color set was the best for this project because I needed a white background and I liked the orange for highlight. I used red for labeling on the diagrams, but it was used sparsely and provided a consistency.
Continue reading ‘ActionScript 3.0 Design Pattern Catalog: Creational Patterns’

Friends with Benefits: State and Factory Method Together at Last—Part II

Published on June 24, 2009 in Design Patterns, Factory Method, Polymorphism and State. by William B. Sanders 6 Comments

In the first part of this article, Friends with Benefits: Refactoring with Multiple Design Patterns—Part I you saw how a Factory Method design pattern was used to hold and deliver data to a DataProvider object. The Factory Method design pattern allowed for easy update by simply adding items to concrete products from a Product interface (DataSupply) or new concrete Product classes. New data can be added to the Concrete Products and the Client makes requests through the Creator interface. The request is filtered through the Concrete Creator to the Product interface to the concrete Product classes. Now, all we need to do is to refactor the player with a design pattern. However, before starting download the application (With 12 classes in the design patterns, a Client class plus three folders of videos, there’s a lot!) So first off, click here to Download All Files . You can see a working version of the player and multiple data sets here. These will help pull together all of the elements used in this project.

Here Comes the Big Bad State Machine

Before we get going on refactoring the video player application, we need to see where it will go in the context of both the State and the Factory Method design patterns. Figure 1 shows the relationship between the refactored player (State) and the factory that delivers the data (Factory Method).
dualdpfilessm
Figure 1: Files for two design patterns in class diagram

The images are organized in an “open” folder, and the videos are placed in separate folders showing their relative position to the classes making up the two design patterns. The Client makes a request through the Factory Method to populate a List component with data from a DataProvider. Then, the request from the Client to the player can be made through the List component by clicking on the video selection. Figure 2 shows what the final product looks like so that you can more easily follow the refactoring:
Continue reading ‘Friends with Benefits: State and Factory Method Together at Last—Part II’