Design Patterns for Coordinating Change Event Listeners

Question

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?

Answer 1

I don't know, if this idea exists already and if it has a name - if so, it would be cool if anybody tell it to us :-)

You could add an object which

• observes your two or three values,
• is observed by your aim object and
• only sends a message, if your condition is reached.

This sounds to me like an "conditional observer proxy".

Answer 2

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:

IObservable<Key> keyPress = 
   Observable.FromEvent<KeyEventArgs>(Application.Current.RootVisual, "KeyUp")
      .Select(ev => ev.EventArgs.Key);

Func<Key, IObservable<Key>> pressedIs = 
   key => keyPress.Where(pressedKey => pressedKey == key);

Func<Key, IObservable<Key>> pressedIsNot = 
   key => keyPress.Where(pressedKey => pressedKey != key);

IObservable<Unit> abcPressed =
   from firstKeyPressEvent in pressedIs(Key.A)
   from secondKeyPressEvent in pressedIs(Key.B).Take(1).Until(pressedIsNot(Key.B))
   from thirdKeyPressEvent in pressedIs(Key.C).Take(1).Until(pressedIsNot(Key.C))
   select new Unit();

abcPressed.Subscribe(()=> Debug.WriteLine("ABC was pressed."));

RxJs is the javascript implementation.

Answer 3

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

Here is some code:

//A State Object is simple encapsulation of runtime activity potentially embedded in Mediator.
var interactionState = { //record state, perhaps array, look up function, or even boolean flag.}

//A Mediator Adds and Removes components, and Broadcasts Events.

//A Mediator loops through added objects and references state to determine if action should be taken.

    for (var c in components) {
        if (typeof components[c]["on" + e] == "function")

          //Add in state comparison
          // if ( interactionState...) //is ready to fire action.
            //{ fire action }

          {
            try {
                //debug("Mediator calling " + e + " on " + c);
                var s = source || components[c];
                components[c]["on" + e].apply(s, a);
            } catch (err) {
                debug(["Mediator error.", e, a, s, err].join(' '));
            }
        }
    }

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.

EDIT: Also check out Evented Views. This is an exceptional article on the topic.