Observer Pattern.

Hook: Interviewers love this pattern because it tests whether you can keep objects loosely coupled while still reacting to change fast.

Question: What is the Observer Pattern?

Answer: The Observer Pattern is a way for one object, called the subject or publisher, to keep a list of dependent objects, called observers or subscribers, and notify them automatically when its state changes. It is useful when one change must update many things, like screens, alerts, or caches, without hard-wiring those classes together. In Java, you usually implement it with your own interfaces; the old java.util.Observable and Observer types are legacy and deprecated.

Interview-Ready Answer: I’d use the Observer pattern when one object changes and several others need to react immediately. My mental model is a newspaper subscription: the newspaper is the subject, and each subscriber gets the new issue automatically. In Java, I’d usually define my own observer interface and keep the subscriber list in the subject; if I have lots of reads and few subscription changes, I like CopyOnWriteArrayList because notifications stay safe even when an observer unsubscribes during an update.

What it is

The Observer Pattern is a behavioral design pattern, which means it focuses on how objects communicate. The main idea is simple: one object changes, and a set of interested objects are told about it automatically. This keeps the subject from knowing details about every listener, which makes the code easier to extend.

How it works under the hood

1. The subject keeps a collection of observers, usually a list or set.
2. An observer registers itself by calling something like addObserver(). This step creates the subscription.
3. When the subject’s state changes, it calls a notification method.
4. The subject loops through the observers and calls their callback method, such as update().
5. Each observer reacts independently: it may redraw a screen, send an email, refresh a cache, or ignore the update.
6. When an observer no longer cares, it unregisters with removeObserver(). This matters because the subject still holds a reference to it, which can otherwise become a memory leak.

There are two common callback styles. In a push model, the subject sends the new data directly. In a pull model, the subject sends an event or reference, and the observer asks for more details if needed. Push is simpler for small updates; pull is useful when observers need different parts of the state.

When and why to use it

• UI events: button clicks, form changes, live dashboards.
• Model-view updates: when a data model changes and the view must refresh.
• Cache invalidation: when one record changes, dependent caches should refresh.
• Notifications: email, SMS, push alerts, audit logs.

Use it when you want loose coupling means the subject and observers depend on small interfaces, not concrete classes. That makes the system easier to add to later, because you can attach a new observer without editing the subject’s core logic.

Observer vs alternatives

Aspect	Observer	Polling	Pub-Sub
Update style	Direct callback	Periodic checks	Brokered event
Coupling	Medium-low	Low	Very low
Latency	Immediate	Interval-based	Immediate
Extra infra	None	Timer loop	Broker/queue
Best for	Local state change	Simple checks	Large distributed systems

Think of Observer as a direct subscription between the subject and listeners. Pub-Sub usually adds a middle layer, such as a broker or event bus, which makes it better for distributed systems. Polling is simpler but wastes time because you keep checking even when nothing changed.

Performance and edge cases

Notification is usually O(n) time because the subject must visit every observer. Registering and removing are often also O(n) if you use a list, because the structure may need to search or copy elements. Space is O(n) for the observer references. In real terms, if you have 1,000 observers and each one spends 2 milliseconds handling an event, a synchronous notification can take about 2 seconds total, which is too slow for a hot path like checkout or login.

A common Java choice is CopyOnWriteArrayList, which copies the underlying array on every write. That sounds expensive, but it is great when reads and notifications are common and subscription changes are rare. If observers are added and removed all the time, a different structure may be better. Also remember to catch failures per observer, otherwise one broken listener can prevent the rest from receiving the update.

One more gotcha: the pattern does not guarantee ordering unless your implementation does. If order matters, define it explicitly. Also be careful with re-entrant updates, where an observer changes the subject again inside update(); that can create loops or surprising cascades.

Real-World Example: Imagine an e-commerce checkout service. The OrderService is the subject, and observers include email receipts, SMS alerts, inventory updates, and analytics tracking. When an order is placed, the service notifies all subscribers so they can react without the checkout code knowing their details.

What goes wrong when teams misunderstand the pattern? A common outage happens when one observer does a slow network call inside the notification path. During a flash sale, the checkout thread waits on that slow listener, request latency spikes, the thread pool fills up, and users see spinning loaders or payment retries. Logs often show timeouts in the listener, not in the main checkout logic, which makes the bug hard to spot unless you know the notification chain.

The fix is usually to keep observers lightweight, catch exceptions per observer, and move slow work to an async queue or background worker. The pattern itself is fine; the mistake is treating every observer like a tiny, fast callback when one of them really behaves like a remote service call.

Follow-up & Tricky Questions:

• How is Observer different from Pub-Sub? Observer is usually a direct subject-to-listener relationship. Pub-Sub often adds a broker or event bus, which decouples senders and receivers even more, especially across services.
• What is push vs pull in Observer? In push, the subject sends the updated data in the callback. In pull, it sends a reference or event object and the observer asks for the details it needs.
• How do you avoid memory leaks? Make sure observers unregister when they are no longer needed, especially in long-lived subjects like singletons, caches, or UI models. If you keep a reference forever, the garbage collector cannot reclaim the observer.
• What data structure would you use for the observer list? If updates are common and subscription changes are rare, CopyOnWriteArrayList is a strong choice because iteration is safe and simple. If membership changes are frequent, you may prefer a concurrent set or another design.
• How would you test it? Test that every observer is notified, that unsubscribe works, that duplicate subscriptions do not double-fire, and that one observer throwing an exception does not stop the rest.
• Is the notification order guaranteed? Not by the pattern itself. If order matters, you must choose and document an ordered implementation.
• Is java.util.Observable the recommended Java API? No. It is legacy and deprecated, so in modern Java you normally build your own observer abstraction or use a newer event/reactive API.
• Can an observer change the subject inside update()? Yes, but that can create re-entrant updates or infinite loops if you are not careful. It is usually safer to keep callbacks small and side-effect aware.

Common Mistakes:

• Forgetting to unsubscribe: This keeps dead objects alive. Fix: always remove listeners when the owner is done.
• Letting one observer crash the chain: One exception should not cancel the rest. Fix: handle failures per observer.
• Doing heavy work inside update: Slow listeners block the subject. Fix: keep callbacks quick or move slow work to an async queue.
• Using the deprecated Java types by habit: Observable and Observer are old. Fix: prefer your own interface or a modern event/reactive approach.

Memory Hook: Think newspaper subscription: the subject is the paper, observers are subscribers, and every new issue is delivered to everyone on the mailing list.

Cheat Sheet:

• One subject, many observers.
• State change triggers automatic notification.
• Use it for UI, alerts, caches, and dashboards.
• Notification cost is usually O(n).
• CopyOnWriteArrayList is good when reads dominate writes.
• Watch for leaks, slow listeners, and re-entrant updates.

Practice Tasks:

• Add a third observer that logs updates to a file.
• Change the demo so observers receive a rich event object instead of a plain string.
• Rewrite the subject to notify observers on a background thread, then observe what new race conditions appear.