Broker architectural pattern in plain english

Question

Could someone explain the Broker pattern to me in plain english? Possibly in terms of Java or a real life analogy.

Elnora

Not sure either. It's possible the downvoter felt this fell under the "does not show research effort", or possibly "too broad" categories. Some older questions are similar to this, but most questions these days usually indicate the current (mis)understanding, and/or indicate where they are confused; otherwise it is usually considered too broad. However, as far as I can tell, this question has never been asked before, and I personally think it contributes to the knowledge base of this site, so (as evidenced by the 3 upvotes and good answer), so it seems to be considered acceptable. +1 – Barlow

I understand what you are saying. I could've included the research I'd done up front, but I wanted keep the question simple. A lot of the time when I end up on stackoverflow the question itself is miles long, whilst the actual question is contained in the title, and a lot of the time the title and the accepted answer is completely independent on the long question text. Maybe I'm overthinking this. My experience as a contributor is very limited after all:) Thanks for useful input though! – Elnora

Yeah, mine are particularly guilty of being long-winded (arguably sometimes needed though). While its true that question-titles sometimes gives you most / all you need to know to answer, the question-description gives you the context. In your case there's no real "context" (unless there is) because you're asking from a general "I don't know" perspective, which is fine. It seems you got a second downvote since last I checked, so maybe next time I might recommend just giving a brief description of what you currently understand and/or what part you're having trouble understanding. Good luck! – Barlow

Answer 1

Try to imagine that 10 people have messages they need to deliver. Another 10 people are expecting messages from the previous group. In an open environment, each person in the first group would have to deliver their message to the recipient manually, so each person has to visit at least one member of the second group. This is inefficient and chaotic.

In broker, there is a control class (in this case the postman) who receives all the messages from group one. The broker then organizes the messages based off destination and does any operations needed, before visiting each recipient once to deliver all messages for them. This is far more efficient.

In software design, this lets remote and heterogeneous classes communicate with each other easily. The control class has an interface which all incoming messages can interact with so a sorts of messages can be sent and interpreted correctly. Keep in mind this is not very scalable, so it loses effectiveness for larger systems.

Hope this helped!

Eaton

Oh! Excellent. So the Broker quickly becomes the bottleneck when there's too many "people" on each side of the line? Kind of like having a single postman for an entire city. – Elnora

exactly! But you can see how well postmen work for smaller groups. Software architecture is all about knowing your needs. – Eaton