Make your own free website on

What is interface ?

Well, I am a self-learn programmer. If you are a beginer, I believe you will get headache like me when you read tutorial written by experienced programmer explaining "interface" with professional words.

If you are beginner, I believe you will get more help from a tutorial written by a non-professional programmer like me.

So, what is inteface ? Like others, I will explain it by examples.

We have various shapes. Square, triangle and circle. There are many common porperties among them. Like, color,rotation, x,y etc. So, we can create a "Shape" class with methods as getColor(), getRotation()......etc.

After we have Shape Class, we start our jobs. Now, we need to create Square class, Circle class and Triangle class. Well, it is simple. Make Square class extends Shape, so Square class will inherit all those methods in Shape. Most of these methods like getColor(), getRotation()... etc, do not need additional codes. We use these methods defined in its Ancestor "Shape" class. We dont need any codes before we can use them. At most, we need small modification only. So does the Circle and Triangle class.

Now, we face another set of "common" methods. We need a method to show the area of the shape. Unlike the function getColor(), the formula to calculate area of square, circle or triangle are totally different from each other. It is impossible to write a general function in the "Shape" class to calculate the area. Thus, although we need a "common" function to show the area of various shape, in fact, there is nothing in common.

For example,

in class Square, we have getRectArea(){return (height*width);};

in class Circle, we have getCircleArea(){return (radius*Math.PI*Math.PI);};

in class Triangle, we have getTriangleArea(){return (height*widht/2);};

OK, that goes without any problems. But, are'nt they all serve as a method to calculate Area ? Good programmer will try to give all these methods the same name - for example "getArea". Other wise, we need Square.getRectArea() to know the area. Circle.getCircleArea() to know the area and Triangle.getTriangleArea() to get the area of triangle instance. Although the formula is different, a common method name means they function the same goal. And, that make them more like "the same kind" of thing. 

Here comes the interface.

interface RegularShape{
    var getArea();

Lets modify our class Circle by :
class Circle extends Shape implements RegularShape{

After click "check syntax", Flash complains that, we should have a "getArea()" method.

So, we are hint, and we follow the hint. We rename our "getCircleArea" method to "getArea" method. Thus, we use getArea to get the area of a Circle instance instead of getCircleArea();

Also, we implements RegularShape to Square class. And we are forced to rename our getRectArea into getArea(). Same things happen to our Triangle class.

That is all about interface.

" Well, I have seen similar example and tutorial already, and still dont understand what is it for !"

Here are questions and answers that clearify interface more.

After I follow the hint and rename the method to "getArea", can I delete the "implements RegularShape" ? What loss will I get ?

Yes. You can. The only goal we implement the interface is to get hint from the compiler. After we follow the hint and do the job, the interface is of no use any more. "class Circle extends Shape" will be enough. Adding "implement RegularShape" will not give your Circle class any additional ability or functions.

However, you should just keep it there.

When you see those words, you know this Circle class "is" a RegularShape. You check the file "" and knows that you can use getArea to get the area of any instance of Circle. Thus, any Class that "is" RegularShape", such as Circle, Square and Triangle will surely have a getArea method to get the area of the shape. If you delete those words, you get to review the detail of the member methods to figure out what is the method name for getting the area. 

Maybe two weeks later, you need modify your Circle class and you might have forgot the hint and decide to give "getArea" a "better" name. Although the class still works, it might affect many codes you did before. And you lost the "protocol" common to other class.

So, if a compiler does not complain, the interface thing is just a bullshit ?

Yes, you are right.

So, "implements RegularShape" does not "give" class an ability to getArea ?

The correct phrase is: "implements interface RegularShape" forces author to write codes to create a method "getArea". If a class implements RegularShape, it "shall" have an ability to "getArea". The compiler does not give it the ability, you shall. The compiler just does not allow it without the ability.

But, interface is widely used. There must be some important applications by interface.

Well, making those functions with "common" name seems trivial, making a "protocol" is a big benefits. Think about that, you have 5 circle, 6 square and 3 triangle. You want to sum up the area of these shape, you can use a for loop calling a common "getArea" method. You dont need to write many "if". "if isSquare, area=getRectArea else if isCircle, area=getCircleSize .......". You see, interface is very important in the concept of "classification".

Why not put getArea in Shape and let they inherit them ? Why bother interface ?

Well, we dont know what shape it will be , so we dont know how to write getArea() method in class Shape. And, it will be non-sence to call getArea() by the Shape class. Anyway, when we extend the Shape class into Circle, Square or Triangle, we need different codes to over-write this getArea() function in the shape if any. So, if the method getArea() only makes sense in the Subclass, why bother making a getArea() in the Ancestor class ?

And, if we put a getArea method in the Shape class, then the script "implement RegularShape interface" will fail to function. The compiler wont warn us or hint us to make a reasonable getArea method because the subclass already has a getArea method inherited from superClass. We must "remember" that we need over-write the abstract getArea method. Are there other methods we need to modify ? We need to review all the methods including those getColor, getRotation methods and pick up what seems unreasonable and write a new one to over-write it. In java, the nonsense getArea method in Shape can be declared as "abstract". This is not support in action script.

Here we have a rough rule. If some methods in Square, Circle and Triangle are common in the exact codes details, (for example getColor, getRotation), we would make the method "inherited". If some methods in Square, Circle and Triangle are common only in the "abstract concepts" we like to apply an interface to force they equiped a common method name..

Lets assume that, we need Square, Circle and Triangle class to pop up a dialog each time we calculate the area. In such condition, we have reasons to make this popup action in Shape and all subclass will inherit this popup function.

I download an library. It contains many class files and an interface file "". There declares a method "fly();". The documentation says, if an instance belongs to a Class that implement "flyable", we can call fly() to make the instance fly. So, I copy that file and create a class Plane implement flyable, will my Plane fly ?

When you do so and check syntax, the compiler will complains: please write codes to make your Plane fly. You get to use your brain to write fly() method to fly. You implement flyable, so you get to make your Plane FLYABLE. How to make it fly is your job. It will not make a fly() function for you. It just wont allow you to be without fly() function.

If you pass the syntax check, then your Plane surely has a method fly() and is Flyable. (Flyable means you can fly(), not necessarily fly to the sky. It depends on what codes you write in the function.);

But, I dont know how to write fly() method, what can I do. The lazy way is searching the library. Find a class "". Possibly the Bird class implement flyable and surely has a fly() method. So, you make your class Plane extends Bird. Then your Plane will be Flyable like Bird. It flies by the fly() mthod inherited from Bird. Of-course, your Plane will also fly by flipping the wings, unless you "over-ride" the fly() method.

So , "class Plane extends Bird" gives something, "class Plane implements flyable" gives nothing ?

Yes, it gives nothing. The interface is to create a protocol among classes. If you are going to use those Bird classes and make your Plane as a member of those flyable classes then your Plane should implements flyable. 

This is common in a company when many programmer cooperate to create various classes that need a common fly() methods. The boss write an interface file "" which contains only 3 lines. Then the boss gives this simple file to each programmer to make classes which implements Flyable. This ensures that each Class will be able to fly and the method to fly will be named as fly(). Otherwise, John may create a class with a method Fly(), Tom creates a method fly() and Mary creates a method flies();

It is a magic that the boss writes only 3 lines of codes to make all classes that implements flyable be flyable.