event object = transfer object?

Thread view:

VisionSet - 15 Dec 2005 17:46 GMT

An event object is typically of concrete type, and passes between packages,
so is it a transfer object? It seems to fulfil the role of one.
Is an event object considered so trivial that it is not equipped with an
interface? ie does the reasoning go, "how else would you implement one?"

--
Mike W

Reply to this Message

VisionSet - 16 Dec 2005 14:57 GMT

> An event object is typically of concrete type, and passes between packages,
> so is it a transfer object? It seems to fulfil the role of one.
> Is an event object considered so trivial that it is not equipped with an
> interface? ie does the reasoning go, "how else would you implement one?"

Does nobody really have an opinion on this?
I'd have thought there would have been at least a minor flood gate opened on
this one!

--
Mike W

Reply to this Message

Roedy Green - 16 Dec 2005 16:20 GMT

>Is an event object considered so trivial that it is not equipped with an
>interface

Since events derive from java.awt.AWTEvent that acts like your
interface.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

VisionSet - 16 Dec 2005 17:06 GMT

> >Is an event object considered so trivial that it is not equipped with an
> >interface
>
> Since events derive from java.awt.AWTEvent that acts like your
> interface.

you mean java.util.EventObject

And that's if they do for your apps custom events.
I guess there is no real reason not to subclass it.
And I guess it is as good as an interface and you're unlikely to want to
subclass something else.
I guess it just comes down to legacy.
It's just that my event object stands out like a sore thumb in my
interpackage dependencies, which is what prompted the musing.

--
Mike W

Reply to this Message

Stefan Schulz - 16 Dec 2005 17:37 GMT

> Is an event object considered so trivial that it is not equipped with an
> interface? ie does the reasoning go, "how else would you implement one?"

Every object has an interface, it may however not implement an explicit
interface. In the case of an Event, there is common functionality (present
in java.util.EventObject) which can be accessed through the interface of
that class.

Since EventObject already exists, why reinvent the wheel, and add a new
"Event Interface" which i would have to explicitly implement if the code
from EventObject can be reused?

Signature

You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"

Reply to this Message

VisionSet - 16 Dec 2005 18:41 GMT

> > Is an event object considered so trivial that it is not equipped with an
> > interface? ie does the reasoning go, "how else would you implement one?"
[quoted text clipped - 7 lines]
> "Event Interface" which i would have to explicitly implement if the code
> from EventObject can be reused?

This argument does not separate EventObject from any other concrete
implementation of other classes for which 'explicit' interfaces exist. Eg
why use TableModel when DefaultTableModel does the job?

I expect the real answer is, as I suggest, that EventObject is so trivial,
it's as good as an interface, and as I later added you are very unlikely to
want to subclass something else and if you do, then nothing says you have to
subclass EventObject.

--
Mike W

Reply to this Message

Stefan Schulz - 17 Dec 2005 13:04 GMT

>> Since EventObject already exists, why reinvent the wheel, and add a new
>> "Event Interface" which i would have to explicitly implement if the code
[quoted text clipped - 3 lines]
> implementation of other classes for which 'explicit' interfaces exist. Eg
> why use TableModel when DefaultTableModel does the job?

I disagree here. I would usually favor an interface if in principle,
completely different implementations are possible or likely (see
ListModel), while favoring a direct implementation if that implementation
is the only one likely ever to be used (such as in EventObject).

Signature

You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"

Reply to this Message

VisionSet - 17 Dec 2005 13:10 GMT

> >> Since EventObject already exists, why reinvent the wheel, and add a new
> >> "Event Interface" which i would have to explicitly implement if the code
[quoted text clipped - 8 lines]
> ListModel), while favoring a direct implementation if that implementation
> is the only one likely ever to be used (such as in EventObject).

You misunderstand me, I would also favour TableModel for anything other than
the very trivial.
I was merely turning you argument around hence:

Since DefaultTableModel already exists, why reinvent the wheel, and add a
[new]
TableModel Interface which i would have to explicitly implement if the code
from DefaultTableModel can be reused?

--
Mike W

Reply to this Message

event object = transfer object?

Free Magazines