O'Reilly logo

ActionScript 3.0 Design Patterns by Chandima Cumaranatunge, William Sanders

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Principles of Design Pattern Development

The founding principles of design patterns are laid down in the Gang of Four's (GoF) canon, Design Patterns: Elements of Reusable Object-Oriented Software. The two essential principles are:

  • Program to an interface, not an implementation

  • Favor object composition over class inheritance

If you skipped the section on the four basic OOP principles because you already know them, the first principle of Design Pattern OOP was introduced, but only briefly. Not to worry, we'll go over it in detail.

Before going further, we need to clarify some basic terms. While these terms are fairly simple, they can trip you up if you don't understand how they're used in context. The subsequent chapters use these terms a good deal, and a misunderstanding at the outset can lead to confusion now and later.

Implementation

For the most part, the term implementation is a noun referring to the details—the actual code—in a program. So when referring to an implementation, the reference is to the actual program as it is coded. Implementation is the internal details of a program, but is often used to refer to a method or class itself.

You may run into some confusion when the keyword implements refers to contracting with an interface structure. For example, the line

class MyClass implements IMyInterface

has the effect of passing the interface of IMyInterface to MyClass. To say that MyClass implements IMyInterface really means that MyClass promises to use all the signatures of IMyInterface and add the coding details to them. So the phrase MyClass implemented IMyInterface means that MyClass took all of the methods in IMyInterface and added the code necessary to make them do something while preserving their signatures.

One of the two main principles of design pattern programming is program to an interface, not an implementation. However, you must remember that implementation is employed in different contexts, and its specific meaning depends on these contexts. Throughout this book, you will see references to implementation used again and again with different design patterns, and you need to consider the other elements being discussed where the term is used.

State

The term state is not part of the ActionScript 3.0 lexicon (like implements is), but the term is used in discussing design patterns. Essentially, state is used to refer to an object's current condition. For the most part you will see state used to convey the value of a key variable. Imagine a class with a single method with a Boolean value set in the method. The Boolean can either be true or false. So its state is either true or false—which could represent on/off, allow/disallow, or any number of binary conditions. The exact meaning of true or false depends on the position of the class in the rest of the design pattern. A more specific example would be an object that plays and stops an MP3 file. If the MP3 is playing, it's in a play state, while if it's not playing, it's in a stop state.

One use of state is in the context of a state machine and the State design pattern you will be seeing in Chapter 10. A state engine is a data structure made up of a state network where changes in state affect the entire application. The State design pattern is centered on an object's behavior changing when its internal state changes. The term state here is a bit more contextually rich because it is the key concept around which the design pattern has been built.

In general, though, when you see state used, it's just referring to the current value of an object's variables.

Client and Request

In this age of the Internet and Web, the term client is used to differentiate the requesting source from the server from which a request is being made. We think of client/server pairs. Moreover, the term request is used to indicate that a Web page has been called from the server.

In the context of design patterns, instead of a client/server pair, think of a client/object pair. A request is what the client sends to the object to get it to perform an operation—launch a method. In this context, a request is the only way to get an object to execute a method's operations. The request is the only way to launch an operation since the object's internal state cannot be accessed directly because of encapsulation.

Note

Don't forget Flash Media Server clients and servers! If you work with Flash Media Server 2, you're aware of client-side and server-side programs. You can launch a server-side method with a request from a client-side object. However, you can launch a client-side operation with a client-side request as well and a server-side method with a server-side request. So if you're using Flash Media Server 2, you're just going to have to keep the concepts separate.

In a nutshell, the client is the source of a request to an object's method. A quick example shows exactly what this looks like. Example 1-37 and Example 1-38 make up an application that does nothing except show a client making a request to an object.

Example 1-37. MyObject.as

package
{
    public class MyObject
    {
        private var fire:String;

        public function MyObject():void {}
        public function worksForRequest():void
        {
            fire="This was requested by a client";
            trace(fire);
        }
    }
}

The MyObject class' sole method is worksForRequest(). The method is encapsulated, so it should have only a single way to launch its operations. Fortunately, all we need to do is create an instance of the class, and add the method to the instance to make it work, as Example 1-38 shows.

Example 1-38. MyClient.as

package
{
    import flash.display.Sprite;

    public class MyClient extends Sprite
    {
        var myClient:MyObject;
        public function MyClient():void
        {
            myClient=new MyObject();
            myClient.worksForRequest();
        }
    }
}

The output tells the whole story:

This was requested by a client

The client in this case is simply an instance of the object whose method it requests. The client/object relationship is through the request. Often the client adds specific details through a parameter, but the concept of a request is usually nothing more than invoking the method with an instance of the object that owns the method.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required