Messager pattern from Panda3D


/ Published in: Python
Save to your folder(s)

This is my implementation of the messager pattern used by Panda3D for event
handling. It's a really nice idea but I think Panda's version is implemented
weirdly, it uses the subscribe objects as keys in the dictionary. That means
that if you want more than one object to subscribe to the same message you
_have_ to subclass DirectObject and use self.accept(...), can't just call the
messager directly or you'll get a different behaviour, it means that a single
object instance can't subscribe two different functions to the same message, and
it means that your _objects_ have to be _hashable_ (!) because the messager uses
them as keys in a dictionary. It seems to me that it would be much simpler if
the messager's dictionary just mapped message names to function objects, so
that's what I did.

Use this pattern when you have a lot of objects spread throughout the class
hierarchy that need to communicate with each other. It's a way of implementing
one-to-many or many-to-many communication, in which an object can send a message
to many receivers without needing to know who those receivers are, or how many
receivers there are, or even if there are any receivers (although an object can
potentially check all these things if it wants to). The singleton messager
object receives messages from broadcaster objects and forwards them to receiver
objects. Setup a single, simple, generic, system- wide messaging system, instead
of creating different systems for each different type of message or messaging
relation.

The disadvantage of just implementing this pattern once and using it everywhere
is that with lots of senders and receivers it might become difficult to
understand and debug message-based behaviour. Particularly if the order in which
messages are sent and received becomes important, when you send a message with
this pattern there's no way of knowing in what order the receiver objects will
receive the message, and therefore know way of knowing in what order their
responses will be executed, and those responses may include sending more
messages. You can implement some ordering relations by having an object receive
a message, deal with it, then send a different message to other recievers, but I
wouldn't want to overuse that.

Also you have to be careful to avoid clashes in message names.

The GoF Mediator and Observer patterns are similar in that they enable a mode
of communication between objects in which the sender object broadcasts a
message without needing to know all of the receiver objects, and the receiver
objects can receive messages without being tightly coupled to the sender
object(s).

In the GoF Mediator pattern, the Mediator object is more than just a messager
that passes messages between other objects and leaves the behaviour up to the
others. The mediator actually encapsulates the interaction behaviour between
objects, deciding which methods to call on which objects each time it receives
a notification from an object. Mediator centralises control of how objects
cooperate in the mediator class, whereas the Messager pattern leaves this
control distributed throughout the objects themselves.

In the GoF observer pattern a one-to-many dependency is setup, there is no
separate Messager object but rather the sender object itself maintains the list
of reciever object and notifies them of new messages. With its separate
messager object the Messager pattern enables many-to-many dependencies as well
as one-to-many.

Report this snippet


Comments

RSS Icon Subscribe to comments

You need to login to post a comment.