There are a lot of good ActionScript 3 books out there, but in most of them all the examples about inheritance, composition, interface, polymorphism and more complex object oriented principles are done using data classes. It’s good to explain the principles, but when you are ready to code some actual classes in Flash, some problems start to arise. Most of my problems come from the fact that 90% of the time I am coding classes that are a visual representation of something. So these classes extends the Sprite or MovieClip class.
So I was coding this game class where I have multiple kind of monsters but I want to use the same functions without checking what kind of monster it is. This is a case where polymorphism comes in handy. The thing is I didn’t do my classes of monster using inheritance (which maybe I should have done), so in order to use polymorphism, I have to create an interface with the public methods common to all my monster classes. So I open the Colin Moock book and start looking at how to code interfaces. Here is a list of quick facts that will help you while doing so.
- You have to list all public methods that will be common for the classes that implements this interface;
- You do so by writing the definition of the function, its name, its parameters and its return type;
- You don’t have to open and close curly braces after the method definition
- You don’t specify if the method is private, public or protected (that’s kind of obvious but I did that mistake)
- interface can only extend other interfaces
- a class can implement more than one interface
So here is an example of an interface in As3:
package com.mutantfarm.monster{ public interface IMonster { function getShot(damage:uint):void; function getCanShoot():Boolean; } }
Here is how my visual class implements this interface while also extending the MovieClip class:
public class spriteMouton extends MovieClip implements IMonster{
It is important that you put the extend keyword before the implement keyword.
So most of what I just wrote about was details about interfaces, but when you start coding, all these details are important to know.
Here are two more article I wrote about interfaces:
#1 by yohami - January 2nd, 2008 at 05:36
Hi Zeh. How does this save time? all the methods in the interface have to be defined again on each class, right?
#2 by dgelineau - January 3rd, 2008 at 01:47
You use interfaces and polymorphism when you want to code in a way that is more maintainable. If the flash compiler is set to soft (it won’t complain for type error) then you don’t have to bother with that.
But if your code is going to be used for more than one project or by more than one person, I would advise using this kind of technique. Having your compiler in strict mode is really good for catching error before they arise.
So in my case, I wanted to check if I could shoot this monster or hurt it. I had to tell the compiler which monster it was in order to use the getShoot method. In a complex game, it could have been one type of monster from a dozen type and I would have to check the current monster against each type. Instead I make sure that every monster implements the IMonster interface and because of that the compiler will throw me an error if I don’t code a getShoot and canGetShoot method with the same definition as in the interface (same parameters and return type).
When I will shoot a monster, I only have to cast any monster to the IMonster type and I am sure it will have the previously mentionned methods. In time it will save me trouble, which might not be obvious at first.
#3 by yohami - January 3rd, 2008 at 16:26
Hi dgelineau,
Thanks. I get it. I thought the interface methods would be inherited or utilized, but they are just a template to make sure a certain class meets the standards. I will probably use it too.
Cheers,
Yohami
#4 by Will - December 7th, 2008 at 15:57
Are you sure this is correct?
I’m pretty sure you can’t apply an interface to display objects as you will get a type error when you add it to the display list. Take the following for example:
var myMonster:IMonster = new spriteMouton();
addChild(myMonster);
This will throw a type coercion error because as far as IMonster is concerned it know’s nothing about inheriting from a DisplayObject.
#5 by Dan - December 14th, 2008 at 23:54
Hey Will, you can cast your object to DisplayObject to add it.
var myMonster:IMonster = new spriteMouton();
addChild( DisplayObject( myMonster ) );
#6 by g - December 25th, 2008 at 10:22
thats pretty good explanation in the comment, dgelineau.
#7 by David - February 17th, 2009 at 15:11
Regarding casting a spriteMouton to Displayobject.
The IMonster interface could be extended to the interface of the DisplayObject and thereby ensuring that classes implementing the IMonster always must extend DisplayObject hence no need to type cast. Just a thought.
#8 by zedia.net - February 17th, 2009 at 16:56
@David
In ActionScript, an interface cannot extend another class, it can only implement another interface, so we cannot do what you are saying, but it would be nice to do so.
#9 by Paul - February 22nd, 2009 at 01:43
Shouldn’t :
be:
As mentioned above the Interface is not a Class and therefore will throw type errors because it is not a type. If it is declared correctly there should be no need for coercion / casting.
#10 by zedia.net - February 23rd, 2009 at 15:58
@Paul
Yes and No, if what you are looking for is polymorphism then you probably want to cast your object to an interface.
Now you could just do what you say and later push myMonster into an array and when retrieving it, cast it to the interface and that would work just as good. It all depends of the context of your application.
#11 by steve76 - March 18th, 2009 at 12:02
@post 10
I think that You never will do a cast in the Paul code.
You can use myMonster as MovieClip or implementation of a IMonster interface without casting in every method that receive as parameters or an MovieClip or an IMonster.
I’m a newbee from the point of view of AS3, but I work with PHP5, C++, Java and so on and that is the main rule ( I suppose so ). am I in fault for AS3?
Bye,Ste
#12 by red tuttle - March 28th, 2009 at 15:01
Is there an easy way to check if a particular object implements an interface?
I have a collection of objects of type IFoo, of which any of them may or may not implement a certain interface, maybe IBar or whatever.
in C# I would do:
if (foo.type is IBar)
But is is not a keyword in CS3
#13 by zedia.net - March 28th, 2009 at 15:50
You can in Actionscript 3 use the is keyword like this:
if (entityList[i] is IBar) {
I have used it and it works perfectly.
#14 by John Giotta - April 16th, 2009 at 09:43
Interace is useful when dealing with shared asset libraries as well. You may refer to the interface class in the application for general definitions of what implementing class will define. Much like intrinsic did for AS2.
#15 by ad - April 26th, 2009 at 16:34
Just tried this for the first time and found no need for casting.
#16 by Fraanske - July 14th, 2009 at 14:53
if (monsterInstance as IMonster)
{
// monsterInstance implements IMonster
} else {
// monsterInstance does not implement IMonster
}
trace(monsterInstance as IMonster)
// Traces either a monsterInstance or null
This is the simplest Interface check I could come up with.
#17 by Joshua - August 19th, 2009 at 18:12
You can also use the “as” parameter.
var newMonster:IMonster = new ScaryMonster ();
addChild (newMonster as DisplayObject);
#18 by brecht - August 28th, 2009 at 06:38
this doesn’t work because you can’t call the displayObject specific parameters like x, y, addEventListener and so on. There has to be another way to make movieclips subject to an interface without losing it’s displayObject specific methods and params. Anyone?
#19 by brecht - August 28th, 2009 at 06:42
Well i guess you can just cast to DisplayObject everytime you need a property but still…
#20 by Weeble - December 15th, 2009 at 10:31
very usefull explanation, I’ve struggled to get my head round this for a while now and you helped clear it up. Thanks!