LiveDocs Comments - flash - 9.0 - main - 00000067.html

flash/9.0/main/00000067.html

bobw2829 — 2008-01-11T10:52:30

Also, correct me if I'm wrong, interfaces can be intregal in downcasting - which is comparing two different object types that share the same interface. For example, if you have object type foo and object type bar, and if they both implement the same Interface, you can compare the two objects.

flash/9.0/main/00000067.html

adbe_paul — 2007-11-15T15:09:44

@petkusj:

Yes, for most of the programming that most people will be doing, you won't need to create interfaces. The most common case where you'd create an interface is if you're creating a class library or framework that is designed for other developers to use. Another common use of interfaces is if you're using what are called "design patterns" -- which are essentially strategies for structuring applications to solve specific programming problems.

And yes, it'll be more common for you to be extending classes and/or implementing interfaces...and if you're writing a class that implements an interface, there's a good chance that in that class you're also extending another class (as in the example I gave).

The good news is that, if the library/framework is designed well, you can often make use of the default implementation (if there is one) to help you implement the interface. For instance, if I'm writing a class that implements IEventDispatcher because I can't extend EventDispatcher, I can still create and use an EventDispatcher internally in my class as a "helper", so that I don't have to recreate the functionality that's already built into EventDispatcher. Here's a minimal example of an IEventDispatcher that uses EventDispatcher internally to do its work (a common way to say this is that you "incorporate the class using 'composition' rather than 'inheritance'"). It definitely requires more code than just extending EventDispatcher, but the good news is that the code can be identical for any IEventDispatcher that includes an EventDispatcher by composition, and as you can see all the work is really done by the EventDispatcher instance that's included in the class:

package
{
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;

public class MyClass extends MyNonEventClass implements IEventDispatcher
{
//
// IEventDispatcher implementation
//
private var _eventDispatcher:EventDispatcher;

public function MyClass()
{
_eventDispatcher = new EventDispatcher(this);
}

public function addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false):void
{
_eventDispatcher.addEventListener(type, listener, useCapture, priority);
}

public function dispatchEvent(event:Event):Boolean
{
return _eventDispatcher.dispatchEvent(event);
}

public function hasEventListener(type:String):Boolean
{
return _eventDispatcher.hasEventListener(type);
}

public function removeEventListener(type:String, listener:Function, useCapture:Boolean = false):void
{
_eventDispatcher.removeEventListener(type, listener, useCapture);
}

public function willTrigger(type:String):Boolean
{
return _eventDispatcher.willTrigger(type);
}
}
}

flash/9.0/main/00000067.html

petkusj — 2007-11-15T09:51:54

Thanks, adbe_paul. When you say:

In that case, if there was no IEventDispatcher interface and only an
EventDispatcher class, you would have to choose to either 1) not use the
built-in event handling mechanisms for the class, or 2) not be able to make
the class a MyNonEventClass subclass (and hence wouldn't be able to use
it for it's intended purpose).

You're kind of saying I get to eat my cake and have it too.

It seems to me, however, that for most of the programming I will be doing, I
probably won't need to create interfaces. But I may often be extending or
implementing interfaces. In your example, it seems I would be both
extending AND implementing an interface?

Jennifer

PS I think I answered my own question.

flash/9.0/main/00000067.html

adbe_paul — 2007-11-14T16:49:11

@petkusj (Jennifer)

You're absolutely right that an interface only makes sense when it's used by more than one class. Specifically, an interface is useful when you're writing code that other developers are going to be using, or that you will be using in a future time for a purpose that you might not be able to anticipate. The idea behind using an interface is to make the code flexible.

Often, as you've noted, a library of code (such as the ActionScript core classes) includes an interface, and also includes one class that implements the interface (often referred to as the "default" implementation). The idea is that for most needs, the default implementation will be sufficient/useable, but in case it's not a developer can create their own class that implements the interface, and can still use it in place of the default implementation.

For a concrete example, consider the IEventDispatcher interface and the EventDispatcher class. Every class that will be part of the ActionScript 3.0 event model must implement the IEventDispatcher interface, because there are places in ActionScript where IEventDispatcher is used as the data type of a property or a method parameter, and objects that dispatch events must be able to be used in those cases. In the vast majority of cases, if you want to create a class that will dispatch events, you can make that class a subclass of EventDispatcher, and the class inherits all the functionality it needs for dispatching events.

What happens, however, if you are creating a class that will dispatch events (we'll call it "MyClass") and you *also* need the class to expose some other functionality that's part of a different (non-EventDispatcher) class; for instance, imagine you need to be able to assign MyClass instances to a property whose data type is a non-EventDispatcher class (e.g. MyNonEventClass). In that case, in order to assign MyClass instances to that property, MyClass would have to be a MyNonEventClass subclass.

In that case, if there was no IEventDispatcher interface and only an EventDispatcher class, you would have to choose to either 1) not use the built-in event handling mechanisms for the class, or 2) not be able to make the class a MyNonEventClass subclass (and hence wouldn't be able to use it for it's intended purpose).

As it is, however, you could make MyClass be a MyNonEventClass subclass, *and* implement the IEventDispatcher interface, and by doing so you can use the class in both situations (in the built-in event handling framework, and in the places where you need a MyNonEventClass instance).

As I said, in the vast majority of cases you'd just make your class an EventDispatcher subclass, and that's all that you need. But in those cases where you can't, it's sure handy to have that IEventDispatcher interface. (For a real-world example, once I was creating a flash.utils.Proxy subclass, but I wanted to be able to dispatch events as well. Since Proxy isn't an EventDispatcher subclass, I had to implement IEventDispatcher.)

Sorry this is so long, and hopefully it is helpful.

flash/9.0/main/00000067.html

petkusj — 2007-11-13T17:29:11

What's the purpose behind the interface? All it really seems to do is keep
me one step removed from manipulating the properties of a class. I
understand that a class can implement more than one interface and
several classes can implement the same interface and I guess I see how
that might be useful, but most of the interface names I've seen appear to
be pretty specific: IEventDispatcher seems inextricably linked to
EventDispatcher and ICellRenderer to CellRenderer. Does Flash compile
faster because an interface was created? It certainly doesn't seem any
easier to use.

Am I correct in thinking that an interface only makes sense when it is used
by more than one class? That it would be pointless to make an interface
for only one class?

Jennifer