Observer Pattern Explained

The Observer pattern lets one object notify many others when something changes, without hardcoding who those others are. It's a subscription model — observers register their interest and get updates automatically. The key benefit is loose coupling: the subject only knows that observers implement a common interface, not their concrete classes. Let me use a cart service example. When a user adds an item to their cart, you might need to reserve inventory, recalculate shipping, and log analytics. Without Observer, the Cart class would directly call inventoryService dot reserve, shippingCalculator dot update, and analyticsLogger dot log — that's tight coupling, and adding a new reaction means editing Cart. With Observer, Cart just loops over its registered observers and calls their update method. Each service implements the observer interface and reacts on its own. You can add a recommendation service later without touching Cart at all. In Spring Boot you'd express this with ApplicationEventPublisher — you publish a CartUpdatedEvent and mark listener methods with at EventListener, and Spring registers them for you. The biggest pitfall to mention is the memory leak. If observers never unregister, they can't be garbage collected even when you're done with them, because the subject's list still holds them. So always provide a removeObserver method and call it when the observer's life ends. And if you're iterating the observer list during notification, use a copy or CopyOnWriteArrayList so you don't hit a ConcurrentModificationException when an observer removes itself.