Does Extends == Inheritance && Implements == Composition?

[justSteve]

In the context of making sure I'm getting my head around the fundamentals correctly....

When I read this statement from LiveDocs EventDistpatcher
(http://livedocs.adobe.com/flex/201/langref/index.html):

In general, the easiest way for a user-defined class to gain event
dispatching capabilities is to extend EventDispatcher. If this is
impossible (that is, if the class is already extending another class),
you can instead implement the IEventDispatcher interface, create an
EventDispatcher member, and write simple hooks to route calls into the
aggregated EventDispatcher.

my understanding of Inheritance and Composition leads me to think this is also a true statement:

In general, the easiest way for a user-defined class to gain event
dispatching capabilities is to use inheritance. If this is impossible
(that is, if the class is already extending another class), or you
employ the logic in Advanced AS3 Design Patterns you can favor
composition over Inheritance and save yourself the opportunity to
extend some other case in the process.

thx
--steve...

[puremvc]

Just so, Steve.

You only get to inherit (extend) once, and so if you want to inherit from somewhere that doesn't have (in this case) the methods called for by the IEventDispatcher interface, then you can implement those methods yourself, and say 'implements IEventDispatcher'. Then you can extend something else if you'd like.

The excerpt you were looking at was further saying that the easiest way to implement the IEventDispatcher is to make a property of some type that does implement the interface, and then your implementation methods just pass the calls along to that dispatcher you're holding.

-=Cliff>

[justSteve]

Thankx Cliff...i'm slowly getting closer to comfortable with composition. I'd posted here cuz I'd giving up on having the same question replied to at the flexcoders list. Then of course, someone _did pick up the thread and took a bit of a different angle than you.


Any thoughts most welcome
<<

Not exactly. The method described in the docs is actually combining
implementing an interface with composition. So you might give your
class a private var called myED that is an instance of EventDispatcher
(thats the composition part). But by implementing the IEventDispatcher
interface, you allow other classes to make calls like this:

myClass.dispatchEvent(...) instead of myClass.myED.dispatchEvent(...)

In the second case you would also have to make myED public of course.
The way they recommend doing it is really a great example of
encapsulation, because it hides the implementation (the fact that a
member var is doing the actual dispatching) and just makes your class
appear to have event dispatching capabilities (which is really all the
other classes should care about). Hopefully that all makes sense.

I can also think of plenty of cases where extending EventDispatcher
would be perfectly adequate and appropriate, so I wouldn't say that
composition is always better than inheritance.

[firemaledragon]

In the spirit of "There are no dumb questions"...

"So you might give your class a private var called myED that is an instance of EventDispatcher (thats the composition part). But by implementing the IEventDispatcher interface, you allow other classes to make calls like this:

myClass.dispatchEvent(...) instead of myClass.myED.dispatchEvent(...)"

To my (beginner's) mind myClass would need to define all of the public methods in IEventDispatcher to fulfill it's contract and then manually delegate calls to myED within each of one these methods - seems like a lot of typing?

However perhaps I'm missing something clever e.g. perhaps myClass fulfills its contract to implement IEventDispatcher merely by composing with myED:EventDispatcher? And then "knows"  how to delegate myClass.dispatchEvent(...) to the composed object myED?

Cheers, Rich

[puremvc]

Rich,

The myED example is a classic way if implementing an interface by composition rather than inheritance. Yes it is aot of typing, but it frees you to extend another class.Since we don't have multiple inheritence we may occasionally need to do this sort of thing.

-=Cliff>

[julien]

In Flex 1.5 and AS2, there was another way to do it, which looks like Aspect Programming.
You just had to declare "dummy" methods in you class, the ones that would implement EventDispatcher behaviour (3 methods I guess)
Then you had to write something like

MyClass
{
constructor
{
   EventDispatcher.initialize(this)
}

and at runtime, your empty methods were "filled-in" with live code from EventDispatcher, and they worked fine.

In AS3, this is not possible (at least I did not find how) directly.
However, it is still possible through the Proxy class, that allows to hook the getProperty and executeMethod behaviour.
Then, it is possible to create a class with dynamic methods (aspects), by adding methods at runtime
Obvious drawback is that you loose class lookup at compile-time, in the IDE
But still, it may be great to use in some cases, like proxy classes or mutating classes ...
kohinoor