Sign in to follow this  
Trapper Zoid

Terminology for message/event passing system

Recommended Posts

This is a fairly straight-forward question. I'm just interested in knowing what a couple of specific algorithmic techniques are called. I'm working on a message/signal/event based system at the heart of my next little game, but I'm confused at the correct name for the message passing techniques I use. This doesn't matter so much for my own work, but I'd like to use standard naming if it exists so when I discuss it with other people I'm not using confusing terminology. I use two different message/event passing algorithms. The first (let's call it Type A) is a simple one-to-many construct; you can use the Type A construct like a function, except instead of sending information to just one chunk of code it will send it to any number of registered chunks (zero to infinity in theory). All of the recipients will eventually get the information. Usually in my implementations you can choose which order the recipients will be called in, but it's bad form to write code to rely on this. The second (Type B) is very similar to Type A, except the recipients are ordered and can choose to block any subsequent recipients from getting the information. This is used for when you wish to pass the info along a chain of handlers until you find one that's prepared to deal with the information; useful for things like GUIs. Is there a specific name for Type A versus Type B? I tend to use names like "signals" for Type A and "events" for Type B, but I'm not convinced I've chosen the most correct naming system there.

Share this post


Link to post
Share on other sites
The terminology I user to would describe the two methods are:
Type A is a publisher/subscriber (or subject/observer) pattern
Type B is a chain of responsibility pattern.

Share this post


Link to post
Share on other sites
Quote:
Original post by dmail
The terminology I user to would describe the two methods are:
Type A is a publisher/subscriber (or subject/observer) pattern
Type B is a chain of responsibility pattern.

Ah yes, patterns! I probably should be talking in terms of patterns. I don't think I was ever formally taught them at uni; I keep thinking of them as "stock techniques for solving program design problems".

I've heard of the publisher/subscriber model for message passing, but I don't think I've heard of the "chain of responsibility" before. It sounds a bit like what the Lord Mayor would wear or a really bad reality TV show, but I guess it fits the bill. Both are a bit hard to express in terms of a class or module name however.

Share this post


Link to post
Share on other sites
Pretty much has been said so I just add some terminology:

* In Java world you are going to bump into "Listeners" when dealing with GUI event handling.

* In .NET world this is called the Event / Delegate pattern (Event is the source of notification, Delegate is the consumer).

Both systems are based on the Observer pattern.

Good example of the Chain of responsibility pattern is the Windows Messages system which lies at the heart of every windows application and is used for a lot more than passing GUI events. Your window procedure receives messages from the message loop and handles only those, you are interested with, passing others to the so called DefaultWindowProc. This is very easily implemented in procedural languages like C. The term for adding a chain link (window procedure) on top of the processing chain is called Subclassing in the Windows API world.

It is interesting that most Observer (Event) based object oriented GUI systems are in fact implemented on top of the good old procedural message loop (Chain of responsibility) system.


Share this post


Link to post
Share on other sites
That's actually where I first learned about these patterns; from using it in various languages as part of GUI systems. The different terminology used is why I kept getting confused over what to call them.

Nowadays I use message passing as the core info passing system in the games I make, as I find it decouples all the modules from each other very nicely.

Share this post


Link to post
Share on other sites
Keep in mind that Boost.Signal uses the terminology signals and slots. It's the exact same thing, and I've found it really damn useful for GUI programming.

Share this post


Link to post
Share on other sites
Quote:
Original post by _goat
Keep in mind that Boost.Signal uses the terminology signals and slots. It's the exact same thing, and I've found it really damn useful for GUI programming.
About half the C++ world uses the signals/slots nomenclature - possibly popularised by Trolltech's QT, which bases all event handling around them.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this