Using the Decorator Pattern for a Real Web Site

With all the concrete components in place, the next step will be to construct the decorator class and the concrete decorators. Like the components they decorate, they too will need an identification and price property as well as methods to return them. The abstract decorator will set that up so that the derived classes have the necessary properties and methods.

The options abstract decorator

As you have seen with other abstract decorator classes in this chapter, it’s one of the simplest classes. Because it extends the abstract concrete component class, it inherits all the class’ properties. However, we need to re-implement the getter function so that we can further reimplement it for the delegations the different concrete decorators use. Example 4-43 shows the abstract decorator class to be saved as Decorator.as.

Example 4-43. Decorator.as

package
{
   //Abstract class
   public class Decorator extends Auto
   {
      override public function getInformation():String
      {
         return information;
      }
   }
}

Because theinformationvariable is inherited from the Auto class, we need not redefine it here. It represents an abstract string.

The options concrete decorators

The concrete decorators generate the information that adds the information property and price value to each option. As a concrete component is wrapped in each, the string data are added to any other strings that wrap the component. So, when the getInformation() method launches, it first gets the delegated information from all other options and the concrete component it wraps. In order not to get a huge string that we cannot unravel, a tilde (~) on the end of the added string will help separate all the different decorations. Examples 4-44 through 4-47 are labeled with the filenames used to save the class.

Example 4-44. HeatedSeat.as

package
{
   public class HeatedSeats extends Decorator
   {
      private var auto:Auto;
      public function HeatedSeats(auto:Auto)
      {
         this.auto=auto;
      }
      override public function getInformation():String
      {
         return auto.getInformation() + " Heated Seats~";
      }
      override public function price():Number
      {
         return 350.78 + auto.price();
      }
   }
}

Example 4-45. GPS.as

package
{
   public class GPS extends Decorator
   {
      private var auto:Auto;
      public function GPS(auto:Auto)
      {
         this.auto=auto;
      }
      override public function getInformation():String
      {
         return auto.getInformation() +
            " Global Positioning System~";
      }
      override public function price():Number
      {
         return 345.88 + auto.price();
      }
   }
}

Example 4-46. RearViewVideo.as

package
{
   public class RearViewVideo extends Decorator
   {
      private var auto:Auto;
      public function RearViewVideo(auto:Auto)
      {
         this.auto=auto;
      }
      override public function getInformation():String
      {
         return auto.getInformation() + " Rear View Video~";
      }
      override public function price():Number
      {
         return 560.75 + auto.price();
      }
   }
}

Example 4-47. MP3.as

package
{
   public class MP3 extends Decorator
   {
      private var auto:Auto;
      public function MP3(auto:Auto)
      {
         this.auto=auto;
      }
      override public function getInformation():String
      {
         return auto.getInformation() + " MP3 Player~";
      }
      override public function price():Number
      {
         return 267.55 + auto.price();
      }
   }
}

For this particular application, we’re not concerned with separating the individual costs. In fact, we want each cost to be accumulated with the others, including the cost of the concrete component we’re decorating. So while the string value needs the tilde (~) for demarcation purposes, we don’t need it for the numeric value.