Archive for the 'Flash' Category

Page 2 of 7

ActionScript 3.0 Abstract Factory Design Pattern: Multiple Products and Factories

Published on January 25, 2009 in Abstract Classes, Abstract Factory, ActionScript, Flash and Flex. by William B. Sanders 7 Comments

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.

abfactory66

 

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.
Continue reading ‘ActionScript 3.0 Abstract Factory Design Pattern: Multiple Products and Factories’

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’

Take a Design Pattern to Work Part III : Loosening Up

Published on January 7, 2009 in ActionScript, Design Patterns, Design Patterns at Work, Flash, Flex and OOP. by William B. Sanders 6 Comments

Gentle Reader:This is Part 3 of a four-part series of posts on introducing design patterns and OOP into the work place. Reading Parts 1 and 2 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. More so than most posts, we invite your comments.

Doing the Loosen Up

Few of you remember Archie Bell and the Drells, but their song, Tighten Up was a big hit back in the day. With design patterns, we want to do the opposite, Loosen Up. At this point, we’re going to do the Loosen Up. So put on your dancing shoes and look at the post No New is Good New. The purpose of the post is to get us to think about relationships between objects in a programming design. The dictum, program to an interface and not an implementation is invoked, and the post discusses different kinds of relationships found in design pattern diagrams. If you’re not sure about the issues involved, that post will help understand the next step in introducing design patterns to work.

At this stage in the series, we have arrived at one of the pillars of OOP, inheritance. Figure 1 shows a simple diagram of where we are now in refactoring the original application that used ActionScript on the Timeline.

inheritance

Figure 1: Inheritance from a parent class

As you saw, inheritance allows developers to use the properties and methods of existing classes and in so doing saves time and adds consistency. However, a standard inheritance model also requires the client to instantiate all of the child classes that must be used. True, the instantiation can be through the parent class by initially typing the objects as the parent class rather than the child class as the following shows:

private var hci:Staff;
hci = new HCI();

The purpose of instantiating the parent is to make the link more general and flexible without breaking encapsulation. If the parent class changes, the objects typed to the parent have a better chance of working well without modification.

Continue reading ‘Take a Design Pattern to Work Part III : Loosening Up’

Take a Design Pattern to Work Part II: A Little OOP

Published on January 5, 2009 in ActionScript, Design Patterns, Design Patterns at Work, Flash, Flex and OOP. by William B. Sanders 9 Comments

Gentle Readers: Before reading this post, you’re advised to look at Take a Design Pattern to Work Part I: Identifying the Problem. It provides the necessary context for this post. Also, keep in mind that this series of posts is walking through a process and some of the steps may seem way too simple. We’re trying to imagine communicating with others who may not be as technically adept as you, and each step is simplified.

Getting Off the Timeline

As the readers of this blog are well aware, the Timeline in Flash is a valuable tool for animation. By using the Timeline in conjunction with symbols, IK and tweening, all kinds of wonderful creations are possible. However, the Timeline is not a good place for code, and again, this is nothing new to readers of this blog. So why bring it up?

If you peruse the ActionScript job openings at places like Dice.com and Monster.com, you’ll find openings that include the following requirements:

The successful candidate should have at least three years experience using ActionScript 2.0 with knowledge of ActionScript 3.0 a plus. He/she should also have the ability to maintain and update legacy Flash sites with ActionScript 1.0. A knowledge of OO programming and design patterns is strongly desirable.

Work that includes maintaining a site written in ActionScript 1.0 (and even ActionScript 2.0 in some cases) almost certainly means that some or all of the code is written on the Timeline and possibly even embedded in the individual symbols —buttons and movie clips. In other words, a good deal of the work is playing Where’s Waldo? with the ActionScript scattered all over the place. For me, working to maintain such a site is somewhere south of Dante’s 9th Circle of Hell. (You remember Dante’s Divine Comedy from that humanities class you had to take.)

In Part I of this post series, the code is embedded in an ActionScript layer on the Timeline. Maintaining the site is pretty simple both in making changes and adding new materials. The developer makes changes by changing the image file and the text contents in any single keyframe. Additions are made by adding keyframes in the Options layer, code in the ActionScript layer and buttons in the Buttons layer. That’s not a difficult plan. So why change?

With a relatively small staff in the company, there’s probably no reason to change it at all. However, as the staff grows or they want to add more to the site, especially in terms of additional graphics and animated materials, the size of the SWF file grows as well. Pretty soon, you’re making pre-loaders, and that’s a good sign that you’re in trouble.

In addition to the problems in generating a big fat SWF file, a single set of ActionScript statements can only grow into a larger and less manageable set of code. For a small application, it works fine, but as applications grow, unless some of the inherent problems are addressed, an error prone application begins to emerge. Change becomes more problematic and the program begins to lose functionality as well as flexibility.

Continue reading ‘Take a Design Pattern to Work Part II: A Little OOP’

Take a Design Pattern to Work Part I: Identifying the Problem

Published on January 1, 2009 in ActionScript, Design Patterns, Design Patterns at Work, Flash, Flex and OOP. by William B. Sanders 6 Comments

New Year’s Resolution

Happy New Year! Now’s the time to resolve to be better in many ways, and one compartment of improvement for me is in programming. In this time of multitasking, I find that I can do a lot better if I focus on one thing at a time, and so compartmentalization really helps—sort of like encapsulation. Further, I find it helpful to have a plan on how to go about whatever change I want to make; so this year my plan is step-by-step to improve my programming habits. However, the first step is to identify the problem and deal with the realities in the problem.

Lions Led by Asses

During World War II in North Africa, one German commander described the British army as lions led by asses. Now I’m not one to claim that developers should take over management and lead us all to a new day and brighter world. However, on occasion I’ve run into situations where someone makes seriously stupid demands that can waste time and possibly destroy a project. Let me share the kind of real-world situation I’m talking about.

During one project, I created an example of bringing in content from external text files using ActionScript 3.0. The example was to show how to create dynamic text in a simple text file so that customers could change text files and maintain the content of their own Web site. For the content I provided an example of travel to very poor countries by a clueless vacationer. One of the people responsible for reviewing the program examples threw a tizzy fit and claimed I was mocking poor countries and demanded that I re-do the entire program. (Actually I was mocking the lack of awareness of poverty, but the reviewer didn’t get that either.) As anyone reading this blog realizes, all I had to do was to change the content of the example text file, and that would solve the problem of what was viewed as political incorrectness.

A long time ago I learned to pick my battles carefully. So rather than going into a detailed explanation of what I was attempting to do and taking a stand against what I saw as monumental ignorance, I simply changed the content of the text file (which was the whole point of the example in the first place). That took all of 10 minutes. The reviewer had every right to tell me to change the content of the example, but she was way out of her depth in telling me to re-write the whole example. That would have been a waste of time and messed up a useful example. She was totally unaware of what the example was all about—the content was immaterial. It was all about flexibility in using ActionScript 3.0 and allowing customers to make changes on their own. Much later in the project, I got a follow-up email from a manager checking to make sure the example was changed. I assured her it was and sent her the revised text files as proof. There was no big fight, angst, and, most importantly, wasted time and effort. We all have only so much psychic energy. It’s the kind of energy we use for working out algorithms, design patterns and other cognitive chores. You’ve only got so much before your brain says, “Enough! I’m pooped!” Don’t waste it on unnecessary fights or gnashing your teeth over bad decisions or unfortunate management choices.

Continue reading ‘Take a Design Pattern to Work Part I: Identifying the Problem’