40 | Chapter 1: Object-Oriented Programming, Design Patterns, and ActionScript 3.0
Example 1-35 has further differences in itsproductDisplay( )details. Instead of either
video or sound operations, it contains operations for loading files. Yet, like the other
two, the signature and interfaces are still the same.
Now that all the classes and the interface are complete, all that’s left is a class to test
the application. As you’ve seen, good OOP and preparation for working with design
patterns suggests programming to the interface and not the implementation as we’ve
been doing. However, in looking at Example 1-36, all the typing (setting the
datatype) is to thePlasma,MP3Player, andComputersimplementations and not the
IBizinterface. This is because each of the implementations extended theSprite
class. So we’re dealing with two supertypes,IBizandSprite. To test the applica-
tion, the instances are typed as one of the specific implementations instead of the
interface. In the section “Program to Interfaces over Implementations” later in this
chapter, you’ll see how to construct your interface and implementation so that you
can still type to the interface when there’s more than a single type in the
Example 1-35. Computers.as
package
{
import flash.display.Loader;
import flash.net.URLRequest;
import flash.display.Sprite;
public class Computers extends Sprite implements IBiz
{
private var hotz:Number;
private var loadPix:Loader;
private var namePix:URLRequest;
public function productDescribe( ):String
{
return "New 10 gHz processor, 30 gigabyte RAM, includes
32 inch screen";
}
public function productPrice(price:Number):String
{
hotz=price;
return "$" + hotz + "\n";
}
public function productDisplay(computer:String):void
{
loadPix=new Loader( );
namePix=new URLRequest(computer);
loadPix.load(namePix);
addChild(loadPix);
}
}
}