0

In observer pattern normally there is a one-to-many relationship between the subject and observers (there are one subject and many observers).

But I have a problem where in my implementation, there are many subjects (eg: A, B, C) that are returning objects but only one observer (eg: O) is there to take outputs of those subjects into a queue and process them one after another.

What sort of design pattern / paradigm can I use for this?

Jonny Henly
  • 4,023
  • 4
  • 26
  • 43
ironwood
  • 8,936
  • 15
  • 65
  • 114
  • Hi Jonny, Yes it covers 98% of my question expect the que implementation in observer. – ironwood Apr 12 '16 at 01:28
  • Perhaps a reactive programming solution where the subjects emit event streams and the observer merges them into one unified stream. I'm partial to [ReactFX](https://github.com/TomasMikula/ReactFX), but there are other reactive libraries. Sorry for the short comment, don't have time to write up a proper answer. – John Kugelman Apr 12 '16 at 01:50
  • I'll check that out John. Your comment is valuable although it is short. – ironwood Apr 12 '16 at 01:54

1 Answers1

3

If you need to use a queue you could go with a Producer/Consumer-pattern.

The difference to the Observer-pattern is, that the observer usually knows the observable(s). While in the Producer/Consumer-pattern the observed object (the producer of objects, information, event whatever) and the observer (the consumer) are completely decoupled. The consumer(s) are not affected no matter how many (or even no) producers are present.

And the other difference of course is, that the consumers have to actively poll the queue.

The "challenge" with this pattern is the correct synchronization in accessing the queue on both ends. But of course there are libraries to handle that.

Wolf S
  • 236
  • 1
  • 3
  • Hi Wolf, I think this is the one that I was looking for. I found a good example also with BlockingQueue. http://javarevisited.blogspot.com/2012/02/producer-consumer-design-pattern-with.html?m=1. Thanks! – ironwood Apr 12 '16 at 12:47