Chapter 15. Introduction to Design Patterns

We've covered a lot of territory, both theoretical and practical throughout the first two parts of this book. By now you should have a firm grasp on ActionScript 2.0 syntax and fundamentals, as well as higher-order concepts such as classes, inheritance, composition, and exception handling, plus housekeeping details such as packages, class libraries, and components . So you're well on your way to being a skilled object-oriented programmer. But you may be wondering how to design an application. You're in luck. This chapter is our first stop on our journey through object-oriented design. By the end of Part III, you should be comfortable architecting relationships between classes to address a variety of common scenarios. With time, you'll learn to expand and apply this knowledge to other problems.

At the beginning of every program is a problem, probably one that other programmers have faced before. A design pattern is a widely accepted description, with a recommended solution, of a design or architectural problem in object-oriented programming. Given a specific requirement, a design pattern describes, in general terms, how to structure interacting classes to meet that requirement. In other words, the pattern provides a general blueprint to follow when implementing some aspect of a program.

Design patterns are, by their very nature, generic solutions. For example, one pattern, named Observer , describes how to update many objects when a single object changes state. Another pattern, named Singleton , describes how to ensure that a program creates only a single instance of a class, not multiple instances. The Observer and Singleton patterns each describes a generalized structure that has a myriad of specific uses. For example, the Observer pattern might be used to keep a pie chart and a bar chart in sync, or it might be used to let multiple objects respond to the completion of a game.

A design pattern does not describe the entire structure of an application. For example, a complete architecture for a tile-based adventure game is not a design pattern. Neither does a design pattern describe a specific algorithm or procedure in an application. For example, a path -finding algorithm used by monsters in an adventure game to find their prey is not a design pattern. Design patterns live somewhere between the complete application and the low-level algorithm. They describe how classes and objects should communicate in a generalized situation that might occur in any kind of program. Furthermore, a specific program will often combine several design patterns to build a complex whole from a group of simpler parts.

By programming with design patterns, we profit from the collective experience of the OOP community, exploiting known tricks and avoiding common pitfalls. We also make our code more familiar to other programmers. Design patterns are part of the common OOP vernacular, so we can use them to more quickly and effectively discuss the general implementation of a program. For example, when we tell another knowledgeable programmer, "The log in this application is a Singleton," he immediately understands the structure to which we're referring without even looking at the code. What might have taken half an hour to explain without reference to an existing design pattern took only a few seconds.

Many of the design patterns that exist in OOP today were first documented by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. In 1994, those four authors published the canonical Design Patterns: Elements Of Reusable Object-Oriented Software (Addison-Wesley). The book, known affectionately as GoF (Gang of Four), defined a formal system for describing a design pattern and presented 23 patterns, many of which are still well-known and commonly used today.

The formal design pattern format laid out by GoF includes four general parts: the pattern name , the problem, the solution, and the consequences. Those general parts are broken down into the following sections:

Pattern Name and Classification

Intent

Also Known As

Motivation

Applicability

Structure

Participants

Collaborations

Consequences

Implementation

Sample Code

Known Uses

Related Patterns

Our consideration of design patterns in ActionScript is informal, so it doesn't use the preceding categories. Similarly, many design patterns include formal UML (Unified Modeling Language) diagrams, but this book doesn't use UML. The emphasis here is on the concepts, not the formal notation. If you've never heard of UML or design patterns before but you've understood Parts I and II of this book, you'll be able to keep up quite easily.

If after finishing Part III, you're keen to learn more about design patterns, you should definitely purchase a copy of GoF. The theory in that book is language agnostic , but the examples focus on C++ and Smalltalk.

Here's an excerpt from GoF that introduces the concept of design patterns. It should give you a feel for the tone of the book (while also giving the present text an opportunity to pay homage to its groundbreaking work):

[Design patterns are] descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.

A design pattern names , abstracts, and identifies the key aspects of a common design structure that make it useful for creating reusable object-oriented design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities. Each design pattern focuses on a particular object-oriented design problem or issue. It describes when it applies, whether it can be applied in view of other object-oriented design constraints, and the consequences and trade-offs of its use.

If you know Java (or are willing to learn a little), you might also try Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process , by Craig Larman (Prentice Hall). For a good resource showing source code in Java for many design patterns, see: http://www.fluffycat.com/java/patterns.html. Java's syntax is quite similar to ActionScript 2.0, so the site should be intelligible even to Flash programmers who don't know Java.