Interfacing in Actionscript

It wasn’t until recently that I actually had the occasion where it made/makes a good bit of sense to use interfaces in any of my flash projects. Part of the reason has to do with formerly lacking the time to actually put together projects the right way, under crazy timelines, and part of it has to do with the fact that I’m working on something that needs to stick around for a bit and will possibly be augmented by persons other (and including) myself.

In most flash projects, interfaces are a bit convoluted and require thoughtfully building out to what amounts to an extra class. Most of the time in smaller projects, subclassing “default” classes pretty much gets the job done. To backtrack slightly for those unfamiliar with the term, an interface is an abstract type which is used to designate how classes can be accessed and manipulated. To use the terminology, an interface specifies the interface that must be implemented by a set of classes.

Utilizing Interfaces

Interfaces in actionscript are particularly useful when creating a set of classes that all have the same methods; the interface strictly defines the guidelines that must be followed when creating a new class of this type.

As an example, let us suppose that we are creating a set of shape classes; we will be creating a circle class and a square class. Let us suppose for now that the only method that we want to implement is the getArea() method. Here are our classes:

class Circle {
private var __radius:Number;
private var __type:String = “Circle”;

function Circle() {}

public function getArea():Number {
return (Math.PI * Math.pow(this.__radius, 2));
}
}

class Square {
private var __side:Number;
private var __type:String = “Square”;

function Square() {}

public function getArea():Number {
return (Math.pow(this.__side, 2));
}
}

So, both implement the same methods here. We can define an interface for all new shapes that get created, which must all allow for the calculation of their area (note that by convention, interfaces usually begin with the letter “I”):

interface IShape {
function getArea():Number;
}

You must then go back and change your class definition line in each of the two classes to

class Circle implements IShape { 

and

class Square implements IShape { 

The interface defines how we can interact with shapes. The big advantage of this when working on projects is that when using environments such as Eclipse with FDT, you can specify that something is an IShape without knowing what shape it is specifically, thereby allowing you to build more flexible projects. In addition, rather than the alternative, which would be to type them as Object, you have a way of typing them that works with syntax checking and code hinting, which saves you time in the long run.

Combining Interfaces with Inheritance

Another handy trick to help when coding is to combine the use of interfaces with inheritance. Let’s suppose we want to create a Shape superclass as such:

class Shape extends MovieClip implements IShape{
private var __type:String = “Shape”;

function Shape() {}

public function getArea():Number {
return undefined
}

public function setColor(newColor:Number) {
theColor = new Color(this);
theColor.setRGB(newColor);
}

public function toString():String {
return (“Shape of type: ” + this.__type);
}
}

So, our definitions would change as such:

class Square extends Shape implements IShape { 

Now we have a few added benefits. Our shapes are now subclassed as MovieClips and Shapes, which means that they can inherit methods from the Shape class. All of our shapes have a __type and all are now MovieClips, so all of them can inherit toString() and setColor().

The cool part about this is that in this case, we now can implement the IShape interface (remember, all classes that implement an interface are required to implement the designated methods) without declaring ones inherited from the superclass unless we choose to do so. This means that we don’t have to add toString() and setColor() unless we want to override the ones in the superclass. This is really great when you have several private variables with getters and setters that you want required by the interface, but don’t want to have to duplicate and comment in every single subclass.

Another advantage of using interfaces is that, unlike extending superclasses, classes can implement as many interfaces as you want. For example, you could have a set of Shapes that implement an IAnimation interface as well as the IShape interface. Other types of objects could also implement this same IAnimation interface, so you could call the method pulse(cycleDuration) the same way on both types of class, and your code hinting would tell you that the method pulse requires a number input. This is probably the biggest advantage — being able to type an object as an interface when passing it to another object that wants to treat it as something that has the methods that the interface requires.