10.12.2012 Views

ActionScript 3.0 Design Patterns.pdf - VideoTutorials-bg.com

ActionScript 3.0 Design Patterns.pdf - VideoTutorials-bg.com

ActionScript 3.0 Design Patterns.pdf - VideoTutorials-bg.com

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Key Features<br />

We can understand the Decorator pattern in terms of two key features. Often, developers<br />

want to add unique responsibilities for an object without adding those same<br />

responsibilities to the whole class. Among other design patterns, the Decorator pattern’s<br />

characterized by adding unique responsibilities. The identifying characteristic<br />

of the Decorator pattern is to add responsibilities in a uniquely Decorator fashion.<br />

Wrapping a <strong>com</strong>ponent in an object that adds a responsibility follows a couple of<br />

guidelines:<br />

• Decorators can appear wherever a <strong>com</strong>ponent object can.<br />

• At runtime, you can mix and match <strong>com</strong>binations of decorators as needed.<br />

To understand the Decorator design pattern’s key features, you need to consider<br />

some alternatives to implementing the work the pattern does. Essentially, your<br />

project requires that you add new features and responsibilities to individual objects<br />

rather than the entire class. To do so using inheritance would bloat the class and<br />

change the structure with each new feature. Every single object would inherit all the<br />

features and functionality of every other object, and that’s not what you want.<br />

In this chapter, you will see the term “<strong>com</strong>ponent” a good deal. The<br />

reference to <strong>com</strong>ponent here is wholly unrelated to the <strong>com</strong>ponents in<br />

Flash, used for UIs, Media, Data and other purposes. In the context of<br />

this chapter, a <strong>com</strong>ponent refers to a concrete instance that is decorated<br />

with another concrete instance called a decorator. So, for the<br />

time being, don’t think of <strong>com</strong>ponents as anything other than something<br />

that gets decorated. (In the last application example of a Decorator<br />

design pattern in this chapter, you’ll be using Flash UI<br />

<strong>com</strong>ponents, but by then you’ll be able to distinguish the different<br />

kind of <strong>com</strong>ponents.)<br />

Imagine you’re setting up an automobile dealership site. You can choose between<br />

different models of autos and add different features—options. You can set up<br />

options such as an MP3 player, Global Positioning System (GPS), cloth, vinyl or<br />

leather seat covers, and different kinds of alarm systems. If you use inheritance, every<br />

one of those options would have to be in every object. What’s more, you’d need to<br />

have all the models in your main class as well. That’s absurd! Why would anyone<br />

need both cloth and vinyl seats or be both a Ford Escape and a Chevrolet Malibu?<br />

Then, if a new option were introduced, you’d have to bloat the class with yet another<br />

option for every single object. However, if you can just wrap a single responsibility<br />

around a <strong>com</strong>ponent when and if you need it, you can keep your program slim, trim<br />

and ready to adapt.<br />

The key to understanding the Decorator design pattern is to understand that it uses<br />

inheritance and employs abstract classes; however, as you know from Chapter 2,<br />

<strong>ActionScript</strong> <strong>3.0</strong> doesn’t support abstract classes. You can create classes that work<br />

130 | Chapter 4: Decorator Pattern

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!