I was shocked when I read in a forum on Flash from a developer I really admire that he has never used interfaces as type definitions. He even asked if that really works. I just thought: “Huh! What’s going on?” Thus here a few thinks I learned about interfaces:
The Key Sentence:
Program to interfaces rather concrete implementations.
That’s the sentence you should always keep at the back of your mind while programming. Following this golden rule offers the following advantages:
1. Loose coupling between objects which promotes flexibility. You are not bound to concrete implementations. Thus you can change them easily when you have to without affecting calling code.
2. You can write simple stub implementations to ease the testing of classes. It also enables teams to work in parallel after they have agreed on interfaces.
Interfaces in Flash are sadly not that mature yet. There are a few problems related to working with them in practice. Martin and me came across them during the early days of the as2lib. He has summed them up in two posts on the as2lib blog: Interface Mistakes by Macromedia and :Object is Evil. But even with this limitations you should nevertheless work with interfaces because the advantages much outweigh the problems of them in Flash.
Read on to see interfaces in action.
Example of how interfaces could be used:
Imagine the engine of a car. Every car has one and every engine can be started and stopped. Thus you need an interface called “Engine” with the two operations “start()” and “stop()”.
-
interface Engine {
-
public function start(Void):Void;
-
public function stop(Void):Void;
-
}
You also have an interface called “Car” with (for the sake of the example) only one operation: “setEngine()”.
-
interface Car {
-
public function setEngine(newEngine:Engine):Void;
-
}
Now to become a little more concrete we’ll create three classes: “CarMini”, “FourStrokeEngine” and “EightStrokeEngine”. The class “CarMini” implements the “Car” interface and the two classes “FourStrokeEngine” and “EightStrokeEngine” the interface “Engine”.
-
class CarMini implements Car {
-
private var engine:Engine;
-
public function CarMini(newEngine:Engine) {
-
setEngine(newEngine);
-
}
-
public function setEngine(newEngine:Engine):Void {
-
engine = newEngine;
-
}
-
}
-
-
class FourStrokeEngine implements Engine {
-
public function FourStrokeEngine(Void) {
-
}
-
public function start(Void):Void {
-
// start the lame four stroke engine
-
}
-
public function stop(Void):Void {
-
// stop the lame four stroke engine
-
}
-
}
-
-
class EightStrokeEngine implements Engine {
-
public function EightStrokeEngine(Void) {
-
}
-
public function start(Void):Void {
-
// start the agile eight stroke engine
-
}
-
public function stop(Void):Void {
-
// stop the agile eight stroke engine
-
}
-
}
You buy a Mini with a four stroke engine (because it is the standard). After a few rides you realize that the engine just is too lame. Thus you decide to put a eight stroke engine in. This isn’t a problem at all because you have a standard (the “Engine” interface) for all engines and you do not rely on concrete implementations. What a good luck for you. Because otherwise you had to buy a new car. 
-
// buy the mini
-
var myMini:Car = new CarMini(new FourStrokeEngine());
-
// take a few rides
-
….
-
// decide that you need a faster engine
-
// put the new one in
-
myMini.setEngine(new EightStrokeEngine());
-
// take a few rides
-
…
-
// be happy
