Observer Pattern

The Observer Pattern lets one object notify multiple dependent objects when its state changes, without the subject needing to know their detailed behavior. It is useful for event-driven designs where observers can subscribe and unsubscribe dynamically.

The pattern has a subject that maintains a collection of observers and an observer interface that defines how notifications are received. When relevant state changes, the subject invokes the observer callback, such as `update()`.

Observers register with the subject through methods such as `subscribe()` and can later remove themselves with `unsubscribe()`. The subject typically stores observers in a collection and iterates over them when publishing an event.

The subject should depend on the observer abstraction rather than concrete observer classes. This keeps the publisher loosely coupled to consumers and allows new observer implementations to be added without changing the subject.

In Java backend systems, the pattern appears naturally in event listeners and application-level event handling. For larger distributed systems, messaging systems such as Kafka or a message broker provide related publish-subscribe behavior, but they introduce different concerns such as serialization, delivery guarantees, and network communication.

Key points

• The subject owns or manages a collection of observers.
• Observers receive notifications through a common abstraction.
• Observers can usually subscribe and unsubscribe at runtime.
• The subject depends on an observer interface, reducing coupling.
• Observer is primarily an in-process object design pattern; distributed Pub/Sub systems add messaging infrastructure.

Interview questions

What problem does the Observer Pattern solve?

It solves the problem of notifying multiple dependent objects when another object's state changes. The subject does not need to contain custom logic for every dependent object. Instead, observers implement a common interface and register with the subject. This reduces direct coupling between the source of a change and its consumers.

How would you implement Observer in Java?

I would define an `Observer` interface containing the notification method and a `Subject` class containing a collection of observers. The subject exposes registration and removal operations. When its relevant state changes, it iterates over the collection and invokes the notification method. Concrete observers decide what action to perform.

What are the advantages and disadvantages of the Observer Pattern?

The main advantage is loose coupling: the subject can notify different observer implementations without knowing their concrete types. It also makes adding new consumers relatively straightforward. A drawback is that notification chains can become difficult to trace when many observers react to the same event. Observer execution can also introduce ordering, performance, exception-handling, or lifecycle concerns.

What is the difference between Observer and a message broker such as Kafka?

The Observer Pattern is primarily an in-process object relationship, where the subject directly invokes observer methods. Kafka is a distributed messaging platform where producers and consumers communicate through persisted records and a broker cluster. Kafka provides infrastructure concerns such as partitioning, retention, consumer offsets, and distributed delivery. Therefore, a Java application can implement Observer internally while using Kafka for communication between services.