Observer Pattern Class Diagram with Interfaces

Mermaid code

classDiagram
    class Subject {
        <<interface>>
        +attach(observer) void
        +detach(observer) void
        +notify() void
    }
    class Observer {
        <<interface>>
        +update(event) void
    }
    class StockTicker {
        -List~Observer~ observers
        +setPrice(price) void
    }
    class PriceChart {
        +update(event) void
    }
    class AlertService {
        +update(event) void
    }
    Subject <|.. StockTicker
    Observer <|.. PriceChart
    Observer <|.. AlertService
    StockTicker o-- Observer : notifies

Paste this into any tool that renders Mermaid, or into the editor to change the theme and export PNG or SVG. Syntax reference: Class Diagram guide.

What this diagram shows

Two interfaces sit at the top, marked with the <<interface>> stereotype inside the class body. StockTicker implements Subject and holds a List~Observer~; when setPrice is called it loops over that list and calls update. PriceChart and AlertService implement Observer. The dashed realization arrows (<|..) connect each concrete class to its interface, and the aggregation (o--) from StockTicker to Observer is labelled notifies to show the runtime relationship.

A class diagram is better than a sequence diagram for this pattern because the structure, not one particular notification, is what you are teaching. Pair it with a sequence diagram if you also need to show the order of update calls.

How to adapt it

• Rename StockTicker to your subject (OrderBook, SensorHub, FormState) and the two observers to real consumers in your codebase.
• Add a third observer only if it shows a distinct behavior; two is enough to communicate the one-to-many relationship.
• Swap o-- for a plain association --> if the observer list is passed in rather than owned.
• Add an Event class with +String type and +Decimal value and point update(event) at it with a dependency arrow to document the payload.

FAQ