Delving More Deeply into the Decorator Pattern - Decorating with Multiple Properties
(Page 4 of 4 )
Multiple properties and methods are not difficult to add to components, and the same is true for decorator classes. Instead of a single property and method, you do essentially the same thing using multiple methods and classes. Example 4-20 shows the abstractDecoratorclass, subclassed from theComponentclass. Save the script asDecorator.as.
Example 4-20. Decorator.as
package
{
//Abstract class
public class Decorator extends Component
{
override public function getSoul():String
{
return soul;
}
override public function good():Number
{
return goodness;
}
override public function evil():Number
{
return vice;
}
}
}
As a subclass of theComponentclass, thisDecorator abstract class does nothing more than re-implement the getter functions—one returning a string, and the other two returning a number. The properties that are to be returned were originally defined as properties in theComponentclass, and as a subclass ofComponent, theDecoratorclass doesn’t have to re-implement them. However, as you’ve seen in previous examples, the getter functions are re-implemented. The only difference is that there are more of them. However, the process and logic are the same.
Multiple Method Concrete Decorations
When it comes to the concrete decorations in this example application, we’re going to see something slightly new. First, take a look at example 4-21. It’s a generic example and should not be placed in as actual code. Just look at it. Several actual concrete elements with working code will replace generic values.
Example 4-21. Generic concrete decoration
package
{
//Generic—NOT implemented
public class GoodEvil extends Decorator
{
private var components:Component;
public function GoodEvil(components:Component)
{
this.components=components;
}
override public function getSoul():String
{
return components.getSoul() + "|GoodEvil";
}
override public function good():Number
{
return +/-00 + components.good();
}
override public function evil():Number
{
return +/-00 + components.evil();
}
}
}
If you break down Example 4-21, the first part looks exactly like the previous examples. AComponent instance,components, is instantiated, and the constructor function wraps thecomponentsobject in itself:
var components:Component;
public function GoodEvil(components:Component)
{
this.components=components;
}
Next, the script re-implements the getter function,getSoul(), to return both the current value of the concrete component’s decorations plus its own decoration value. Again, this is what previous examples have done.
override public function getSoul():String
{
return components.getSoul() + "|GoodEvil";
}
The next two functions add or subtract numeric values using thegood()andevil()methods. Each good adds to a good and subtracts from an evil, and vice versa for a vice—adds to evil and subtracts from good. So depending on the concrete decorator, you add or subtract from each of the two return values, and add that to the current value of the concrete component.
override public function good():Number
{
return +/-00 + components.good();
}
override public function evil():Number
{
return +/-00 + components.evil();
}
Examples 4-22 through 4-35 make up the seven deadly (revised) sins and seven heavenly (revised) virtues. However, what they really represent is the flexibility of the Decorator design pattern. (Also, they illustrate the complex issue of saving souls.)
Please check back next week for the continuation of this article.
| 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.
|
|
