All Packages Class Hierarchy This Package Previous Next Index
1. Message input to a part. The part never knows where the message comes from, or whether it's a normal or service Message. Generally the part will check the message name and use one public or protected method per message property supported, unless trivial. The use of those public methods allows the flexibility of direct links (with interfaces) or use of messages. We may need a design standard here.If the message is not expected the class should not throw an exception, but it may complain such as by printing that it's ignoring the message name.2. Sending a message out of a part. This always happens when a message is first sent from a MessageSender. It also occurs behind the scenes when a message is forwarded from one MessageRouter to another MessageRouter.
3. Monitoring messages in a MessageRouter. This is handy for tools and advanced domain parts. For example is allows system animation by visually showing the flow of messages.
The receiver should NOT keep a reference to the message, to allow the sender to reuse message objects. If a reference is needed, do a clone or such.
public abstract void receive(Message message)
The class should check the message name and then do
something per name, much like a method. Remember, the message
name is interned, so == comparison may be used since
it's faster and more concise.
All Packages Class Hierarchy This Package Previous Next Index