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:
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.