Archive for the 'Factory Method' Category

Page 2 of 2

Friends with Benefits: Refactoring with Multiple Design Patterns—Part I

Published on June 16, 2009 in ActionScript, Design Patterns, Examples, Factory Method and State. by William B. Sanders 6 Comments

The Case of the Crowded Client

After I made my video player that I planned to use to illustrate refactoring a non-design pattern program into a design pattern one, I noticed how crowded the Client class had become. Most of the crowding was caused by creating and populating UIs and event handling functions. One class that I use a lot to populate UI components is the DataProvider. As I went through and edited and organized my videos from a vacation to Prague, CZ, the DataProvider kept growing. Using MP4 files converted into F4V files, I used very similar formats for the data portion of all of the DataProvider instance. Why not put the DataProvider data into a separate class? Then, I could just call an instance of the class with the data and not have to clutter the Client class with messy DataProvider information.

Lazy Programming can be a Lot of Work

After moving the DataProvider data to another class, I realized that I had two other projects using the video player that accessed the same kind of data. So, while I was at it, I might as well add classes for these other projects. In fact, why not add a common interface as well? Then I could program all data requests to the interface instead of the implementation. Further, I could add some separation between the DataProvider items and the Client requests by adding a factory, and if I were going to do that, I might as well go ahead and create a Factory Method design pattern. Then, whenever I wanted to add a class with data for different projects I could do so without having to worry about messing up the rest of the program. Each project was handled using a Concrete Product class.

The Big Picture

To begin with a clear idea of what is going on in this refactoring exercise, you’ll need to get the big picture. Figure 1 provides an overview of how the video player is to be refactored using two design patterns:
twodps1

The video player is essentially a state machine, and in Part II of this post, we’ll look at how we’ll refactor the hack-job player into a state player.
Continue reading ‘Friends with Benefits: Refactoring with Multiple Design Patterns—Part I’

Take a Design Pattern to Work Part IV: Establishing a Design Pattern Foundation

Published on January 15, 2009 in Abstract Classes, Design Patterns, Design Patterns at Work, Factory Method, Flash, Flex and OOP. by William B. Sanders 2 Comments

Gentle Reader: This is Part 4 of a four-part series of posts on introducing design patterns and OOP into the work place. Parts 1 through 3 will provide the context for this part. Also, taking a look at No Time for OOP and Design Patterns will give you the background on this series. As always, we invite your comments.

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…).

factorymethoddp852

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.
Continue reading ‘Take a Design Pattern to Work Part IV: Establishing a Design Pattern Foundation’

MVC and Factory Method Pattern Chapters on Adobe DEVNET

Published on September 21, 2007 in Design Patterns, Factory Method and MVC. by Chandima Cumaranatunge 2 Comments

Two chapters from the ActionScript 3.0 Design Patterns book are available as a free download from devnet. Each chapter contains multiple examples. The factory method pattern chapter includes a print shop application, a sprite factory, and a shooter game that uses the factory method pattern to create different types of projectiles. The MVC chapter includes a weather map application and a car chase app.