Yes. For this I returned to the original "Gang of Four" book on Design Patterns, then did some research online.
Here is some code:
//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.
Your implementation of the "apply" behavior is probably different, and may be simplified.
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.
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
This sounds to me like an "conditional observer proxy".
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: