A ProblemPattern.

'''Context:'''

You are using the ObserverPattern with a PushModel, in other words, the observable sends the specific message 'my value has changed to 3' instead of a more vague 'I have changed' message.

'''Forces:'''

You cannot use the more vague PullModel style of messaging because the observers would have a hard time figuring out what changed (for example: addition of an item to an object's member collection.)

'''Problematic scenario:'''

A problem arises when there is more than one observer attached to the observable. Imagine:

	* You change an observable's value to 5. It now broadcasts the message 'value changed: 5' to its observers.

	* The first observer Obs1 receives the message, and in response decides to change the observable's value to 3. ''(Here's the problem)''

	* This causes the observable to broadcast the message 'value changed: 3'. (This broadcast is nested inside the original 'changed value: 5' broadcast.)

	* All observers now receive the 'value changed: 3' message.

	* Now, the original broadcast ('changed value: 5'), which was interrupted by the nested broadcast, is resumed: the observers past Obs1 in the list receive the message 'value changed: 5'. This message certainly is wrong, as the observable's value really is 3 now.

'''Therefore''' your observables should record when they are notifying observers and forbid changes in this state.

I use a boolean member variable mSwitchingStates, which is set true during notification, and reset to false afterwards. If a change is attempted when mSwitchingStates is true, an exception is thrown.

ManuelSimoni

Please comment.
----

While not directly an example of the Observer pattern (really just subclassing that displays behaviour similar to the problem above)... this sort of infinite-change recursion is very easy to get into in heavily event-driven paradigms like the DotNet gui objects.  The problem is that, when (for example) extending a TextBox to be, say, an auto-truncating-textbox, that manipulating the text fires off a slew of events that you may or may not have been observing in order to change the text in the first place.

In this case, it becomes important to note ***what*** is making the change.  If the change is being made by a user, then you want all the clean-up to fire.  If it's being made by internal event handlers or overrides, then the overrides have to consider what other overrides (including themselves) will be responding to the change.  At this point we lose the neat, clean behaviour of the Observer and end up constructing a brittle, heavily co-dependant framework of modifications... but I haven't seen a better way when it comes to adding functionality to event-driven user widgets.

----
'''Known Not-Uses:'''

Various Java Graph libraries do not even mention this case (when adding or removing edges to/from a node.)
----
I think the problem is the nesting of the operations. If you make the notifications and receipts by the observable atomic, it goes away. For example, the observable can have an outgoing message queue and an incoming message queue. When the observable changes state, it places a notification for each observer on the outgoing queue and processes the queue, saving incoming messages from the observers on the incoming queue. Then it processes the incoming queue. At least, that's how I did it. If your observers really do like to set the observable whenever they see the observable changes state though, you could easily get into a nasty positive feedback loop. I'd suggest that such a design needed a fundamental rethink.
----
[Publisher/Subscriber model discussion moved to ObserverPattern]
----
CategoryPattern