views:

65

answers:

4

You have a pull-oriented Observable/Listenable which notifies Observers/Listeners when some state changes.

The state consists of more than one nugget of data, and some of your Observers/Listeners don't care about the whole state.

Do you generally prefer to notify all the Observers/Listeners anyway and allow them to ignore notifications when nothing they care about changed?

Or do you generally prefer a seperate Observable for each "nugget" of data so that your Observers/Listeners are guaranteed to only get notifications they need to respond to?

Does it depend on the situation?

Do you have any general thoughts on the granularity of your Observables/Listenables?

+1  A: 

Well as a general rule of thumb, specialized interfaces do more good than harm, so I would definately implement more rather than less.

This obviously does call to the situation though. Only specialize in this way if it is necessary, and from your situation it seems that way, otherwise it's like informing the makers of the Cereal that the wheat needs harvesting. It simply doesn't apply.

Kyle Rozendo
A: 

If I had to do this, I'd probably create an Observable class which would have an event for each kind of nugget, and one global event for any nugget. Kinda like a middle way.

Vilx-
+1  A: 

You're trading off maintenance costs against costs of delivery. If you have fine-grained Event definitions each observer gets only exactly what he needs, so you don't pay for the overhead of delivery to observers who are uninterested - but that saving costs because every new kind of nugget needs to be added to the system in some way.

In Pub/Sub messaging systems where the delivery costs are relatively high (messages flowing over networks) one typically needs to pay careful attention to the topic deifintions. A carefully designed topic hierarchy is often useful. So we get patterns like

  sport
       football
              england 
                    premier
                    champioship
              scotland
                    spl
              france
                    ...
       cricket
              australia
                    ...
              india
              sri lanka

Hence allowing subscriptions at various levels. You can subscribe to all sport or (as some folks might) right down to

    sport/football/england/championship/watford
djna
If we follow down this road, I think we will arrive at "filtered" events, where a filter can be a function of arbitraru complexity.
Vilx-
agree that this can get interesting, if complex. The driver is the cost of delivery. If in your environment the delivery costs are low (where that might be because of a combination of few observers, few events, low per-unit delviery cost) then keep it simple. When the costs rise (eg. because of network overheads) then the complexity becomes valuable. And should that happen, reusing someone else's patterns (or code) will be helpful.
djna
Prior to asking, this was my preferred way to do it. The big advantage is that if you start with the assumption that you're going to have specialised topics, even if you don't branch very far, you can expand as you need to.
Iain Galloway
A: 

It's not just maintenance. The more specific is the interface between Observables and Observers the more coupled they become.

The Gang Of Four book has a section for this very problem, and they advise against both the push and the pull models. The pull model may be inefficient, the push model may not be reusable enough.

So, it highly depends on the situation. I tend to go slightly above the pull model.