I've been working with the Observer pattern in JavaScript using various popular libraries for a number of years (YUI & jQuery). It's often that I need to observe a set of property value changes (e.g. respond only when 2 or more specific values change). Is there a elegant way to 'subscribe' the handler so that it is only called one time? Is there something I'm missing or doing wrong in my design?

Update 2014-12-9: Thanks for all the great answers! I've recently been using Backbone Models. When a set is invoked with multiple properties the model triggers a change event. Listeners can inspect the changed property for a hash of the properties changed. This approach essentially solves my problem.
–
KreegrDec 10 '14 at 2:03

4 Answers
4

Yes. For this I returned to the original "Gang of Four" book on Design Patterns, then did some research online.

Mediator - Define an object that encapsulates how a set of objects
interact. Mediator promotes loose coupling by keeping objects from
referring to each other explicitly, and it lets you vary their
interaction independently. It is responsible for coordinating interactions for a group of objects.

State - Allow an object to alter its behavior when its internal state
changes.

Here is an example of JavaScript mediator. Skip to the bottom for usage. Other examples may or may not be more relevant for you. But it exemplifies the notion.

"Instead of using the Observer pattern to explicitly set many-to-many
listeners and events, Mediator allows you to broadcast events globally
across colleagues." — Paul Marcotte

Your implementation of the "apply" behavior is probably different, and may be simplified.

Is there a elegant way to 'subscribe' the handler so that it is only called one time?

I wouldn't think of it as 'limiting the events'. There is probably no real performance gain by doing this anyway. The perspective above, is to introduce a decision mechanism that says, "We have had 2 or more objects firing events, lets do this special task".

The Mediator encapsulates the decision mechanism, the state object encapsulates the runtime accumulation of information. Keep in mind that, at some point the state may need to be reset. This cleanup behavior would be sensible to be placed within the Mediator.

It may very well be the case that you can have your Observer listening for published events, then calls the Mediator to review the State, which makes the determination of interaction, if it is relevant, then broadcasts event with instruction to execute their special behavior.

The Reactive Extensions framework was designed to address this issue for .NET event handlers. You may be interested in seeing how RX can let you respond to sequences of events, as described in the "Sequencing Events" section of this blog post. Basically, if you are interested in responding only when the user types "ABC" (in that order), you can say:

One technique (using Event-Based Systems with a Mediator):

I take advantage of the Mediator Pattern quite a bit -- one way to control event-flow is to instantiate different Mediator objects per-module, and pass only a specific Mediator to each module (as a, or in a sandbox) -- this will allow each module to only communicate through that specific medium, only when you say it should -- and, with this method, when you broadcast messages, you won't be broadcasting on the entire system / medium that the ApplicationDirector is listening on. An oversimplified implementation might look something like this:

Now, you can use a Mediator to handle when exactly certain changes (e.g. quantity) have an effect on the rest of the system. You even have more control over when a given module should notify the system of the change(s). Furthermore, if you're developing a very large-scale application -- using a Mediator that implements an EventHub is a good approach.

There are plenty of odd things about this example, but I hope you find this useful for what it demonstrates.

Yes - A Mediator is a great way to manage event flow. My question was more specifically, at the lowest level, wondering how/when to synthesize an event that's based on 2 or more concurrent other events. A Mediator, would still be required to do this.
–
KreegrDec 10 '14 at 1:58

Ah... I think I see. You mean something like an approach to avoiding callbackHell because the context involves the combination of two events. If this is the case, and the events occur between two different modules, you may use some sort of Fly Weight -- update a counter or push to an array on it, but basically use an appDirector to check this property's value, say, ['myFirstEvent', 'mySecondEvent'] and fire some sort of 'bothEventsFired' event to kick off the target-process. You also may want to check out Object.definePropert-y/iesget &set as you could watch batch changes with this.
–
CodyDec 10 '14 at 18:21