C
Chris Berg
In a recent posting thread, I went into a discussion about using event
adapters as opposed to simply implementing the event listener
interface directly. A lot of pro and con can be said about this, but
one argument made me consider an aspect that I have never thought
about.
Generally, I don't like to subclass adapters, because the event
handler method usually requires access to a components fields, which
makes things messy if the listener is a separate class. It is much
easier to let a component implement the listener(s) of choice, leaving
the unused handler methods empty.
Anyway, it was pointed out that a reason to use adapters is that you
are more safe when the listener changes, that is, if another method is
added to the listener in a later version of the VM. Then the
corresponding adapter would of course have the method added, securing
that your application can still run under the new VM.
On first view, this seems to be a good argument, but after thinking a
bit about it, I wonder if that is really a risk? Has Sun actually ever
done that? I mean, putting new methods in an already published
interface seems to be risky, not only if Sun does it, but also if it
happens in a developer team. I would prefer to make a new interface,
which extends the old one and adds new methods.
Comments?
Chris
adapters as opposed to simply implementing the event listener
interface directly. A lot of pro and con can be said about this, but
one argument made me consider an aspect that I have never thought
about.
Generally, I don't like to subclass adapters, because the event
handler method usually requires access to a components fields, which
makes things messy if the listener is a separate class. It is much
easier to let a component implement the listener(s) of choice, leaving
the unused handler methods empty.
Anyway, it was pointed out that a reason to use adapters is that you
are more safe when the listener changes, that is, if another method is
added to the listener in a later version of the VM. Then the
corresponding adapter would of course have the method added, securing
that your application can still run under the new VM.
On first view, this seems to be a good argument, but after thinking a
bit about it, I wonder if that is really a risk? Has Sun actually ever
done that? I mean, putting new methods in an already published
interface seems to be risky, not only if Sun does it, but also if it
happens in a developer team. I would prefer to make a new interface,
which extends the old one and adds new methods.
Comments?
Chris