Observer pattern

In <a href="/facts/Software_design/61rGr5Ej">software design</a> and <a href="/facts/Software_engineering/KX6cE9kz">software engineering</a>, the observer pattern is a <a href="/facts/Software_design_pattern/mV7r4egw">software design pattern</a> in which an object, called the subject (also known as event source or event stream), maintains a list of its dependents, called observers (also known as event sinks), and automatically notifies them of any <a href="/facts/State_(computer_science)/4Yu8xXHS">state changes</a>, typically by calling one of their <a href="/facts/Method_(computer_science)/8kAXxVYs">methods</a>. The subject knows its observers through a standardized interface and manages the subscription list directly.
This pattern creates a one-to-many dependency where multiple observers can listen to a single subject, but the coupling is typically synchronous and direct—the subject calls observer methods when changes occur, though asynchronous implementations using event queues are possible. Unlike the <a href="/facts/Publish-subscribe_pattern/d2aH1etM">publish-subscribe pattern</a>, there is no intermediary broker; the subject and observers have direct references to each other.
It is commonly used to implement <a href="/facts/Event_handling/0YdM6AoB">event handling</a> systems in <a href="/facts/Event-driven_programming/QlGL2Fu6">event-driven programming</a>, particularly in-process systems like GUI toolkits or MVC frameworks. This makes the pattern well-suited to processing data that arrives unpredictably—such as <a href="/facts/User_input/WQTE8Jas">user input</a>, <a href="/facts/HTTP_request/TWtvf7JD">HTTP requests</a>, <a href="/facts/General-purpose_input%2foutput/rIGeu7TW">GPIO</a> signals, updates from <a href="/facts/Distributed_database/A6Q1s4Iy">distributed databases</a>, or changes in a <a href="/facts/Graphical_user_interface/wBlQFWDP">GUI</a> model.

Observer pattern open-in-new

Observer pattern