ActionScript 3.0 Design Patterns

Probably the best place to start a discussion of loose coupling is with an analogy. Suppose you’re on a trip away from home and you want to buy a gift for your child. You don’t know the town you’re in that well, and so you ask the receptionist at your hotel where you can find a toy store. The receptionist suggests a nearby store, and you go there. It’s a big toy store, and so you locate a clerk to help you find the toy you want. After showing you several toys of the kind you’re looking for, you proceed to select one and purchase it. You ask the clerk if you can have the toy gift-wrapped, and she takes the toy to the back room and has it wrapped for you.

The process to locate, purchase and have a toy gift-wrapped involves interacting directly with two people—the hotel receptionist and toy store clerk. A third person may have gift-wrapped the toy, but you don’t know and don’t care. All you care about is getting the toy and having it gift-wrapped. The process is smooth because you are loosely coupled with the people with whom you interact.

You Can’t Handle the Truth

Let’s suppose that the receptionist at the hotel just found out that his girlfriend ran off with a traveling design pattern developer and is heart-broken. You don’t need or want to know that. All you want from the interaction with the receptionist is the location of the toy store. You want loose coupling with the receptionist. Knowing about the receptionist’s internal turmoil won’t get you what you need and may needlessly complicate things because you too are a traveling design pattern developer. Interaction between hotel receptionists and hotel guests is well defined and restricted.
Read more…

Sometimes a concept or principle is so simple that it can fly under the radar and no one understands it. For me, at least, this was the case for the OOP principle, encapsulate what varies. In the context of a program, encapsulation is the process of hiding the internal mechanisms and data structures behind an interface. To use the encapsulated operations (object, component), all the developer needs to know is what the component does. Then when the developer needs the component, all of the operations hidden in it are accessed by some kind of request—composition, inheritance or even simple instantiation.

So far so good. Encapsulation is pretty clear, and by the time you’ve decided to tackle design patterns, you should have some idea of encapsulation from OOP principles. The tricky part may be in understanding what is meant by separating elements that you expect to change and those that you expect to stay the same and encapsulate those that change. For this principle, we’re only interested in those elements that may change. Obviously, variables and data change values all the time, and so if we try to encapsulate everything that changes in a program we can quickly become entangled in a swirling flux of mutable elements.

What May Change?

In a recent Lunch Bucket pattern post that loaded SWF files, I noted that I was thinking about adding modules that would load XML files and text files. In other words, I was thinking about what may need to be changed in the program. So when discussing change the principle is not pointing to variables and data but adding components to the existing structure.

The added components are the change referenced in the principle.

All I really need to add (change in the program) is an algorithm to load XML files and another one to load text files. By choosing the Strategy pattern, I can easily add this new functionality by implementing the strategy interface with a new algorithm. The Strategy design pattern is specifically designed to handle change by adding algorithms; therefore, in that pattern algorithms vary and so they are encapsulated.
Read more…

This post is going to be short and sweet. I worked up a little application that you can see here. Also, I created an AIR version, and it now seems to work on Mac, Windows 7, Windows Vista and Windows XP. You’re welcome to download it here (AIR version) and put it someplace handy where you can quickly look up the main principles guiding OOP and design patterns.

Principles in Your Lunch Bucket

Here’s the whole idea of why I started this project in the first place. We need something that makes it easy to remember and use good practices at work. The posts reviewing OOP and DP principles on this blog is one resource, but something simpler (and sillier) would be helpful to have available when cranking out code under a deadline.

Yes, I practiced what is preached

When developing this little application, I started off the wrong way, and decided that no! Never again! I’d start off right, and it wasn’t any more difficult. I used a Strategy pattern, and later I’ll put the whole thing up here with an explanation of how this “work” project was done by following the dictums I was writing about.

So take a look and let me get your valuable (as always) feedback.

After getting slightly comfortable with the first dictum of design patterns, program to an interface; not an implementation, you may find this next one will knock the support blocks right from under you. In being advised to program to an interface, we get the idea that we type our objects to a superclass (abstract class or interface) and then we actually instantiate the object to a concrete class that is derived from the superclass. Doing so optimizes flexibility and minimizes dependency on implementations.

We assume that we are dealing with some kind of inheritance. It doesn’t matter if the inheritance is from an abstract class or pure interface. However, this next principle,

Favor object composition over class inheritance

looks like if we have a choice, we should avoid inheritance altogether. (We doan need no stinkin’ inheritance!)
Read more…

The first principle of design patterns is,

Program to an interface, not an implementation

Simply put, the Gang of Four urges programmers to declare variables only to abstract classes and interfaces and not concrete implementations. You never want to type your instance as a concrete class derived from an interface or abstract class—only to the interface.

Okay, you may be thinking that we already covered this principle in our book. That’s true. We did in both the introduction (pp. 45-49) and in part of the chapter on the Observer design pattern (pp. 285-288.) We also had a lot of examples, and so why rehash the same principle here? The following reasons seemed compelling enough to warrant additional discussion:

• Includes dynamic binding
• Closely tied to polymorphism
• Built into Creation design patterns
• Easy to ‘take to work’

Before starting, we’ll use the concept of an interface to refer to programs that use either abstract classes or ActionScript 3.0 interface. So, if you see a reference to an interface, it could well be an abstract class. It’s the concept of an interface that’s important; not the ActionScript 3.0 interface statement.
Read more…

Gentle Reader: Now that we’ve worked through all of the design patterns in ActionScript 3.0 from GoF (well, Builder is still in the works, but that’ll be available soon), now would be a good time start going through the principles underlying design patterns. This will be the first in that series.

The 1987 OOPSLA keynote address by Barbara Liskov contained what has become known as the Liskov Substitution Principle (LSP). Essentially, the principle holds that

If a Client is using a reference to a base class it should be able to substitute a derived class for it without affecting the program’s operation 

(Actually Dr. Liskov said something more like:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

but I’m not about to…)

If the Client has an object of a certain type, it should be able to substitute a derived object of the same type. For example, suppose you have an abstract class named Automobile and from that class you have subclasses of Ford, Toyota, and Peugeot. Your Client has an object, myAuto:Automobile. The myAuto object can be any of the subclasses, and if a substitution is made for any one of them everything keeps on working without a problem and the change is unknown to the Client. So if you substitute a Ford for a Toyota, the Client can work with the objects without having to adjust for the change. What’s more, if you want to add a Fiat class as a subclass of Automobile, the myAuto object handles it with nary a whimper.

The one caveat is that the subclasses must all honor the contractual conditions of the parent class. So, any methods in the parent class must be functioning in the subclass (aka, derived class.)

Now you may be thinking, So what? If you’re at all familiar with other principles of OOP and Design Patterns, this principle may sound vaguely familiar, but what is the importance of this concept/principle/idea? It is this: Because the Client is unaware of the concrete class that the object may implement, the structure is far more resilient. Not only can the same structure be reused, it can be changed, updated and generally fiddled with without easily breaking anything. (Think of adding more car manufacturers to the Automobile class.) As far as the Client is concerned, as long as the interface rules are followed with the object, everything is hunky-dory.
Read more…

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

Read more…