Using the Decorator Pattern for a Real Web Site - Implementing the concrete components and their decorators
(Page 6 of 6 )
The pattern implementation process requires that certain things are in place so that the user can choose what she wants as far as both concrete components (car model) and concrete decorators are concerned. Initially, the script must first find which car has been selected. So the function getCar() loops through the radio buttons until it finds which one is selected. When it locates it, it simply assigns an instance of carDeal with one of the concrete components such as:
carDeal = new Mariner();
ThecarDeal object has to be instantiated outside a function so that it can be used by more than a single private function. On line 16 of Example 4-48, thecarDealobject is instantiated as anAutodata type. (Theinternalstatement is added to draw attention to the fact that the variable is available to any caller in the same package—even though it is the default state when instantiating variables.)
Once thecarDealobject has been created, the script looks at the options selected. Using thegetOptions()function, each of the checkboxes is compared to its selection state. When a selected option is found, the option, a concrete decorator, wraps the concrete objectcarDeal. For example, if one of the selections is heated seats, the code section in the switch statement looks like the following:
case "Heated Seats":
carDeal = new HeatedSeats(carDeal);
break;
Because more than one decorator can be selected, as each selected option is located, the concrete object can be wrapped more than once. Thus, any or all of the options can be added to the selected auto.
Summary
The Decorator design pattern excels in adding features to core objects without having to fundamentally change those objects. Like the ornaments on a Christmas tree, the ornaments change the appearance of the tree, but the tree itself is not changed at all. Anything from the appearance of a web site to the contents of an online shopping cart can be structured using a Decorator pattern.
The Decorator should be considered a core design pattern when your project has to be updated with the addition of new objects and new features for those objects. We like to think of the Decorator as a “100-year” pattern. Imagining concrete components as types of people and decorations as the clothes they wear, it’s not too difficult to envision a web site being updated with different kinds of people spanning a century—from a blacksmith at the beginning of the 20th century to a nanotechnologist at the beginning of the 21st century. Likewise, all kinds of people can be styled with a range of clothing over the same time span, from a blacksmith’s leather apron in 1900 to an astronaut’s spacesuit in 2000. However, the programmer who is thinking ahead from one century to the next is able to use a Decorator pattern, and doesn’t have to change the core component at all. He just adds more concrete components and decorators as needed.
At the same time that the Decorator pattern is open to adding new features without changing the structure of the program, both components and decorators can be deleted when they’re no longer needed. Further, changes to existing components and decorators are easy to make without altering anything other than their specifics, such as a string’s label or a number’s value.
The Decorator pattern, though, has certain drawbacks. For example, in this chapter, some readers may have been thinking that they could have programmed the same exact functionality for some of the sample applications using a fraction of the code and far fewer classes. That’s definitely true, and for specific applications, the Decorator design pattern may be like swatting a fly with an elephant gun. However, like all design patterns, the developer has to be judicious in selecting which, if any pattern, he wants to employ. That decision needs to be made not just on the current size of the application, though. When starting any project where the Decorator pattern is considered, you have to ask yourself: are the concrete components and decorators going to grow and change or are they going to be fairly static? So, even though your application may begin as an acorn, you have to envision the oak tree as a possibility and plan accordingly.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 This article is excerpted from chapter four of ActionScript 3.0 Design Patterns Object Oriented Programming Techniques, written by William B. Sanders and Chandima Cumaranatunge (O'Reilly, 2007 ISBN: 0596528469). Check it out today at your favorite bookstore. Buy this book now.
|
|
