Observer pattern: "Web of observers" - Is this ever in use?

Question

I had an idea (which I'm sure already exists), to create a sort of 'network of observers/subjects'. I would like to describe how it works and than ask several questions about it.

Say we have 5 objects: Objects A, B, C, D and E. Objects D and E need to observe objects A, B and C.

With the regular Observer pattern, both D and E would register as observers to A, B and C. This means both D and E would have to register three times as observers, creating six observer-subject relationships total.

The idea is to add another object in the middle, let's call it Object O. It implements both the Observer and Observable interfaces. It registers as an observer to objects A, B and C. Objects D and E register as observers to object O.

Whenever objects A, B and C notify object O, object O notifies it's own observers - D and E. Thus creating a sort of network. This network has a total of five observer-subject relationships.

As I see it, this has two main benefits:

• The less important benefit: This solution allows for less observer-subject relationships, and thus (I think) creates less complexilty in the system. In this simple description the number of relationships only gets reduced by one, but the more observers and subjects there are, the bigger the benefit.

• The more important benefit: Please consider an application with two groups of objects, group A and group B. All objects in group A need to observe all objects in group B. If we decide to add an object to group B, than using regular Observer we'd have to update a lot of code to register all objects in group A as observers to the new object. With the 'network' solution (which I'm sure has a different name), we only register the 'middle' object (object O) as an observer to the new object in group B, and all objects in group A would be notified when the new object in group B changes state.

My questions:

1. Is this solution ever in use in professional projects? Did you ever encounter this in use? Or is it just a cool idea but never used in practice?

2. What would you say are this pattern's disadvantages?

3. Does it have more advantages that I'm not aware of?

4. Does this have a name?

Answer 1

1. Sure, these things exist. D-BUS comes to mind, or any number of messaging frameworks (RabbitMQ , AMQP, ZeroMQ, etc). They're all variations on a similar theme.
2. Increased latency compared to directly-connected peers, and increased complexity for complex topologies.
3. The biggest one I can think of is the ability to extend to multiple WANs and scale to massive numbers of subscribers. (Search for 'message queue federation' to learn more). Also, service discovery. Clients only need to know about the 'router' component in the middle to connect to any service.
4. There are so many variations that it's hard to pick a single name, but I would call it a 'software message bus' or 'message broker'.