The largest single class we’re going to use is the one to create the user interface. The line numbers appear in the Example 4-48 for the purpose of referencing lines in the code. A lot of the work done by this class, named Deal, is to set up the interface objects. These include the radio button, checkbox, and button components. Addi-tionally, a good hunk of code is required for the text field output window and for-matting for the output. So while the interface to the decorator pattern may look unwieldy, it’s not decorator pattern’s fault. In fact, only thegetCar( )(beginning on line 115) andgetOptions( )(beginning on line146) private functions are employed to pull out the information generated by the Decorator pattern.
To get a handle on what the class does, enter the code from Example 4-48 and save it asDeal.as.
}
override public function getInformation( ):String {
return auto.getInformation( ) + " MP3 Player~";
}
override public function price( ):Number {
return 267.55 + auto.price( );
} } }
Example 4-48. Deal.as 1 package
2 {
3 import fl.controls.CheckBox;
4 import fl.controls.RadioButton;
5 import fl.controls.Button;
6 import flash.display.Sprite;
7 import flash.display.MovieClip;
8 import flash.events.MouseEvent;
9 import flash.text.TextField;
10 import flash.text.TextFormat;
11
12 public class Deal extends Sprite 13 {
14 internal var checks:Array=[];
15 internal var cars:Array=[];
Example 4-47. MP3.as (continued)
16 internal var carDeal:Auto;
35 doDeal.addEventListener (MouseEvent.CLICK,getPackage);
36 } 37 //**
38 //Get information from Decorator and display it 39 //**
40 private function getPackage (e:MouseEvent):void 41 {
55 private function formatMachine (format:String):String 56 {
68 dealText.wordWrap=true;
83 var gizmos:Array=new Array("MP3","Heated Seats","GPS", "Rear View Video");
84 var saloon:uint=gizmos.length;
99 var car:Array=new Array("Escape","Mariner","Prius","Accord");
100 var saloon:uint=car.length;
120 {
Creating the document and setting the stage
Once you’ve saved theDeal.asfile, you’ll need to do a little work on a Flash docu-ment file. The following steps will guide you.
1. Open a new Flash document and save it asAutoDealer.flain the same folder as the.as files.
2. In the Document class window, type inDeal, and resave the file.
3. Using Figure 4-8 as a guide, use Static text to add the header “2 Guys From Con-necticut Hybrid Cars.” Beneath the header, at horizontal position 150, type in Select Car, and on the same line at horizontal position 250, type in Select Options.
4. Open the Components and Library panels and drag a copy of the radio button and the checkbox to the Library.
5. Select Insert➝Symbol in the menu bar, and select Button as Type. In the Name window, type in Button (which is the default name), and click the Import for ActionScript checkbox. Click OK to enter the Button Symbol editor indicated by the special four-frame Timeline.
6. In the Button Symbol editor, add a layer, and, selecting the top layer, use the Rectangle Tool to draw a rectangle with colors to suit your tastes with 8-point rounded corners located at x=0, y=0. Size it to W=43, H=13. Add keyframes to all the frames in the top layer. Select the object in the Over frame and swap (reverse) the stroke and fill colors.
7. Add keyframes to the first three frames in the lower layer. In the Up frame, using a Static text and narrow sans serif 10-point font type, type “Calculate” centered below the button. In the Over frame, do the same thing, but type inTotal Cost. Leave the Down frame empty.
8. Check to make sure your Library shows the following: CheckBox, CheckBox-Skins, Component Assets, Button, RadioButton, RadioButtonSkins. If it does, you should be all set.
The next step is to test the application. All the buttons and the text field are auto-matically placed on the stage. Figure 4-8 shows what you can expect to see if every-thing is working as expected.
172 } 173 } 174 } 175
Example 4-48. Deal.as
Implementing the concrete components and their decorators
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 functiongetCar( )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( );
ThecarDealobject 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 atten-tion 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 thecarDeal object has been created, the script looks at the options selected.
Using thegetOptions( ) function, each of the checkboxes is compared to its selec-tion state. When a selected opselec-tion is found, the opselec-tion, 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;
Figure 4-8. Decorator user interface and output
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 hav-ing 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 shop-ping 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 compo-nents as types of people and decorations as the clothes they wear, it’s not too diffi-cult 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 nanotechnolo-gist 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 think-ing 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 com-ponents 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 Decora-tor 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.
Chapter 5