Monthly Archive for September, 2008

ActionScript 3.0 Clone: A Prelude to the Prototype Design Pattern

Published
by
Bill Sanders
on September 23, 2008
in ActionScript, Design Patterns, OOP and Prototype
. 15 Comments

Where’s the Clone()?

The next design pattern I plan to tackle in ActionScript 3.0 is the Prototype Design Pattern. Getting started I ran into the clone() method in other languages like C#. As usual, that wasn’t much help. To my surprise, I found that several classes in ActionScript 3.0 have a clone() method such as the Rectangle class. However, while perfectly functional, cloning a rectangle with origins in the flash.geom namespace isn’t exactly what I had hoped for. (There’s no clone() method in the Shape class where I could make lots of clones of rectangle shapes I could put on the stage.) What I wanted was a way to clone objects.

Borrowing from Java

Buried in the Adobe ActionScript 3.0 Live Docs is a little note about cloning arrays. (see http://livedocs.adobe.com/flex/3/html/10_Lists_of_data_6.html) Using a method commonly found in Java programs, the note indicates that a deep copy clone is possible using this method. One can use concat() or slice() with no arguments to make a shallow copy. In most cases, GoF note that shallow copies will work fine, but for more complex structures a deep copy is required.

The docs list the key method as the following:

import flash.utils.ByteArray;
 
function clone(source:Object):*
{
    var myBA:ByteArray = new ByteArray();
    myBA.writeObject(source);
    myBA.position = 0;
    return(myBA.readObject());
}

That’s a nice little piece of code and simple to understand. The clone() method creates a ByteArray that writes the object (an array) and then returns it by reading the object it just wrote. Moreover, it’s a deep copy and as such a true clone in that all of the parts are delivered and not just pointers.

Continue reading ‘ActionScript 3.0 Clone: A Prelude to the Prototype Design Pattern’

ActionScript Facade Design Pattern: The Cat Herder

Published
by
Bill Sanders
on September 20, 2008
in ActionScript, Facade, Flash, Flex and OOP
. 4 Comments

The bigger and more complex a system based on subsystems gets, the more difficult it is for a client to make requests and get what is expected. The Facade acts as an interface to simplify communication with the elements that make up the subsystem and the client. So instead of communicating with all of the components of the subsystem, the client interacts with a single component, the Facade.

The class diagram for the Façade looks a good deal different from most other design patterns. The classes that make up the subsystem are intentionally vague to represent any subsystem. The problem, though, is clearly illustrated by the network of possible connections between the classes in the subsystem and how a client might run into problems when it needs to interact with them all. Figure 1 shows a modified Façade class diagram. In the original GoF diagram, the client is not listed as a participant—only the Façade and the subsystem classes. However, following the Freemans’ diagram (with some slight adjustments of my own to make it closer to the GoF diagram) I included a client but made it implicit.

Figure 1: Facade Class Diagram
Continue reading ‘ActionScript Facade Design Pattern: The Cat Herder’

No New is Good New: Using Inheritance, Composition, Delegation and anything else other than New in ActionScript 3.0 Design Patterns

Published
by
Bill Sanders
on September 19, 2008
in ActionScript, Design Patterns, Flash, Flex and OOP
. 4 Comments

Before examining why instantiating instances using new is not a good thing, let me explain where I got the idea. It came from the GoF (indirectly) and the Freemans’ Head First Design Patterns (directly). This is not to say that both acquaintance and aggregation type relationships cannot hold a reference to another class by instantiating an instance of the other class. (The Proxy example on this blog does that.) Likewise, it may be impossible to do serious development without using at least some new statements and so the title indeed contains a bit of hyperbole.

The key idea behind design patterns is that you want your programs to be as flexible as possible. The dictum, program to an interface, not an implementation is an invitation to more flexible designs. When you create an instance using new in effect you lock into using the specific implementation. The more new statements in a program, the more tied up it is in whatever implementation you’ve elected to instantiate.

At the same time, I wanted to go over the different class relationships to connect the conceptual with the actual. When I look at a class diagram and see different relationships between classes, often I feel queasy about the relationships independent of a specific example. This is especially true with non-ActionScript 3.0 examples where the application invokes some built-in feature of the alien language. Suddenly, the example is sucked into a black hole remaining a mystery for ActionScript developers. We’ll avoid that here.

Inheritance Is-A First Step

We are advised by the Gang of Four to favor composition over inheritance, but inheritance is a fundamental part of most design patterns, so it’s a good place to start. It’s also the easiest place to show where you can invoke a method without using new, We’ll begin with the symbol in the class diagram in Figure 1.

Figure 1: Inheritance relationship

Continue reading ‘No New is Good New: Using Inheritance, Composition, Delegation and anything else other than New in ActionScript 3.0 Design Patterns’

The Iterator Pattern: Flexible implementation of collections

Published
by
Chandima
on September 4, 2008
in Iterator Pattern
. 7 Comments

We tend to think of the iterator pattern as simply a mechanism to access a collection of items in some sort of order. However, the motivation for the iterator pattern goes quite a bit beyond this everyday requirement. It is specifically designed to hide how you decide to structure the collection, but still provide a uniform interface to traverse and access its elements. We will look at a couple of examples where we change how the collection is implemented but keep the client oblivious to the change.

Let’s take a look at the class diagram to determine the relationships between the classes in the iterator pattern.


Continue reading ‘The Iterator Pattern: Flexible implementation of collections’