I forsee 4 interfaces for QueueElement:
The QueueElement and Signal interfaces are from the SEDA architecture. Beyond
that,
I see a Message interface and a Command interface.
Here are the base interfaces I see:
interface QueueElement {}
interface Signal extends QueueElement {}
interface Message extends QueueElement
{
Object getAttachment();
void attach( Object attachment );
}
interface Command extends Signal, Executable
{
boolean isRepeatable();
long getRepeatInterval();
}
This is all fine and dandy, but I want to get a feel for the getType() that
is
currently part of QueueElement. I added that for the purpose of making tests
quicker and easier. However, there is no easy way to directly correlate a
QueueElement type id to the class from which it came. The issue directly
correlates
to how QueueElement types from different vendors would work in the same system.
One method would have us act as a repository for vendor to id masks. I am
against that aproach. Another would be to mathematically guarantee that all
QueueElements are different deriving the id from the class or class name.
This is better, but it also raises the question of why have it in the first
place?
Please place the vote here:
VOTE
----
Keep getType() method in QueueElement, or kill it?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
