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.

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.

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.

I ran across this site a while back. Not as much detail as the Gang of Four book, but rather handy for looking up and learning about patterns, and it has more than the GoF too. Chain of Responsibility and Observer are, I believe, the two you described.

I believe you are correct, Buzzy. Thanks! I hadn't heard of Chain of Responsibility before, but I guess it's the canon description. I must be pretty rusty on the whole software engineering side of things.

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.

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.