Observer, Mediator, and event bus all decouple communication, but they do so for different coordination needs.

Observer, Mediator, and event bus patterns can all reduce direct coupling, but they solve different communication problems. Observer fits one-to-many notification. Mediator fits centralized collaboration rules. Event bus fits broader publish-subscribe distribution across a system or subsystem.

GoF catalog Which pattern when Previous: Strategy vs State vs Command

Why This Topic Matters

Why this behavioral choice matters

Java systems often need notifications, orchestration, and distributed event flow. If these communication styles blur together, code becomes harder to understand and architectural boundaries become muddy.

Core Explanation

How to separate these behavioral roles

Observer is usually the lightest-weight option: a subject notifies its observers. Mediator is stronger when the problem is not notification but coordination among participants. An event bus goes wider still, acting as an event distribution mechanism across a larger boundary.

In Java applications, these patterns often show up near each other. Domain events may look observer-like, application orchestration may look mediator-like, and asynchronous infrastructure may look event-bus-like. Naming the force precisely keeps the design clearer.

Choose Observer for listeners, Mediator for collaboration logic, and event bus for broader event distribution across components.

Concept Breakdown

The forces behind the choice

Force

Notification fan-out

Observer is best when one subject notifies interested listeners about a change.

Force

Central coordination

Mediator is best when interaction logic among participants needs one coordination point.

Force

Event distribution

Event bus is best when events should flow across a broader set of publishers and subscribers with looser coupling.

Java Example

Behavioral decision sketch in Java

Java example: three communication shapes in one system

package org.javaomnibus.ecommerce.gof.behavioral;

public final class CommunicationChoices {
    OrderConfirmedPublisher observerPublisher() { return null; }
    CheckoutMediator workflowMediator() { return null; }
    DomainEventBus eventBus() { return null; }
}

Code Walkthrough

Step by step

observerPublisher notifies listeners directly through a subscription model.
workflowMediator centralizes collaboration logic across participants.
eventBus distributes events more broadly across publishers and subscribers.
All three reduce direct coupling, but they do not express the same architectural intent.

Real-World Usage

Where this comparison helps

Choosing between listener patterns and orchestration styles
Clarifying event-driven design decisions in Java systems
Separating domain notifications from broader infrastructure messaging

Comparison Table

Pattern	Main force	Scope	Typical Java example
Observer	One-to-many notification	Local subject/listener relationship	Order confirmed listeners
Mediator	Centralized collaboration	Coordinating participants in one flow	Checkout orchestration
Event Bus	Broader event distribution	Subsystem or application-wide messaging	Domain event distribution

Trade-Offs

How to use this guidance responsibly

Loose coupling can improve extensibility but can also hide control flow. The broader the communication model becomes, the more observability and naming discipline matter.

Common Mistakes

Where teams still get confused

Using Observer when the real need is workflow coordination
Building a mediator when a simple notification model would do
Calling every in-process event mechanism an event bus
Letting communication style choices blur the system’s architecture boundaries

Compare the detailed behavioral pages

Observer Mediator