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

Example 1-22. Subclass.as
package
{
//Subclass of Abstract class
public class Subclass extends AbstractClass
{
override function abstractMethod( ):void
{
trace("This is the overidden abstract method");
}
}
}
When the application finally implements the methods originating in the abstract
class, it does so by programming to the interface (AbstractClass) but instantiates
through the subclass (Subclass). So the instance, doDemo, is typed as AbstractClass
but instantiated as Subclass.
Example 1-23. ImplementSub.as
package
{
//Implement Subclass of Abstract class
import flash.display.Sprite;
}
public class ImplementSub extends Sprite
{
private var doDemo:AbstractClass;
}
public function ImplementSub( )
{
doDemo=new Subclass( );
doDemo.abstractMethod( );
doDemo.concreteMethod( );
}
The following shows what appears in the Output window when you test the program:
This is the overidden abstract method
I'm a concrete method from an abstract class
At this point you may be scratching your head wondering why you should go
through this kind of convolution to do what you could do with a non-abstract class.
Instead of subclassing the abstract class, overriding one of the methods, and then
implementing the subclass, we could have just written both methods the way we
wanted them in the first place and not have to override anything. The next section
attempts to answer that question.
32 | Chapter 1: Object-Oriented Programming, Design Patterns, and ActionScript 3.0