Using One Object Per Event Type With Publish And Subscribe (Pub/Sub)

Yesterday, I was reading an interesting article by Miller Medeiros that compared different types of publish and subscribe mechanisms. Publish and Subscribe (Pub/Sub) is nothing new - if you use jQuery at all, you've probably been using Pub/Sub a lot (even without thinking about it). In the article, however, Miller described a Pub/Sub approach that I had never seen before: Signal. In the signal approach, each event type is defined by an individual event beacon. So, rather than binding to a generic event dispatcher, a subscriber would bind to a specific object that codes for a single event type.

In the more generic, flexible approach to event binding, a subscriber would bind to an event beacon, supplying both an event type and an event callback:

In this case, the subscriber is binding to the event type, "someEvent," and would like the function, "subscriberCallback" to be invoked when that event is dispatched. In the Signal approach, the event binding is performed on an event beacon that codes for a specific event:

The main difference here is that in the first approach, "someEvent" is an arbitrary string value; and, in the latter approach, "someEvent" is a property of the evented object.

In theory, both of these approaches are the same - they allow for publishers to expose an event-binding surface; and, they allow subscribers to bind to specific event types. In practice, however, the major difference is that the Signal approach requires a more formalized event architecture; rather than creating just-in-time, string-based event types, each event has to be defined explicitly ahead of time as a property of the evented object before subscribers can even bind to it.

As Miller points out in his pro/cons list, this is probably a good constraint.

Since I had never seen this kind of Pub/Sub architecture before, I thought it would be good to experiment with a little code. And, to make it more fun, I wanted to explore some of the jQuery 1.7 Callbacks information that Addy Osmani discussed in his Demystifying jQuery 1.7's $.Callbacks article. In the following demo, I'm creating a Signal class (which wraps $.Callbacks) and then I'm using it to define several event types on a given object.

As you can see, the Signal class represents a single event type. It then exposes two subscriber methods:

• bind( callback )
• unbind( callback )

This Signal class is then instantiated for each event type available on the "sarah" object. When we bind to events on sarah, we aren't binding to sarah itself; rather, we are binding to the event surface exposed by sarah.

And, when we run the above code, we get the following console output:

Sarah [Shower]: Rubba-dub-dub
Sarah [Shower]: Oooooooh

While this approach does feel a bit awkward, probably due to its novelty, I like the fact that I have to explicitly define my object's event types. I suspect that this would force me to think more holistically about my object architecture. And, I think there would be improved readability and maintainability in being able to see all the events defined in a single place.

You Might Also Be Interested In: