Insoftware design andsoftware engineering, theobserver pattern is asoftware design pattern in which an object, called thesubject (also known asevent source orevent stream), maintains a list of its dependents, calledobservers (also known asevent sinks), and automatically notifies them of anystate changes, typically by calling one of theirmethods. 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 thepublish-subscribe pattern, there is no intermediary broker; the subject and observers have direct references to each other.

It is commonly used to implementevent handling systems inevent-driven programming, particularly in-process systems like GUI toolkits or MVC frameworks. This makes the pattern well-suited to processing data that arrives unpredictably—such asuser input,HTTP requests,GPIO signals, updates fromdistributed databases, or changes in aGUI model.

The observer design pattern is a behavioural pattern listed among the 23 well-known"Gang of Four" design patterns that address recurring design challenges in order to design flexible and reusable object-oriented software, yielding objects that are easier to implement, change, test, and reuse.^[1]

The observer pattern addresses the following requirements:^[2]

• A one-to-many dependency between objects should be defined without making the objects tightly coupled.
• When one object changes state, an open-ended number of dependent objects should be updated automatically.
• An object can notify multiple other objects.

The naive approach would be for one object (subject) to directly call specific methods on each dependent object. This creates tight coupling because the subject must know the concrete types and specific interfaces of all dependent objects, making the code inflexible and hard to extend. However, this direct approach may be preferable in performance-critical scenarios (such as low-level kernel structures or real-time systems) where the overhead of abstraction is unacceptable and compile-time optimization is crucial.

The observer pattern provides a more flexible alternative by establishing a standard notification protocol:

1. DefineSubject andObserver objects with standardized interfaces.
2. When a subject changes state, all registered observers are notified and updated automatically.
3. The subject manages its own state while also maintaining a list of observers and notifying them of state changes by calling theirupdate() operation.
4. The responsibility of observers is to register and unregister themselves with a subject (in order to be notified of state changes) and to update their state (to synchronize it with the subject's state) when they are notified.

This approach makes subject and observers loosely coupled through interface standardization. The subject only needs to know that observers implement theupdate() method—it has no knowledge of observers' concrete types or internal implementation details. Observers can be added and removed independently at run time.

The observer pattern and thepublish–subscribe pattern are closely related and often confused, as both support one-to-many communication between components. However, they differ significantly in architecture, degree of coupling, and common use cases.

The table below summarizes the key differences:

In practice, publish–subscribe systems evolved to address several limitations of the observer pattern. A typical observer implementation creates a tight coupling between the subject and its observers. This may limit scalability, flexibility, and maintainability, especially in distributed environments. Subjects and observers must conform to a shared interface, and both parties are aware of each other’s presence.

To reduce this coupling, publish–subscribe systems introduce a message broker or event bus that intermediates between publishers and subscribers. This additional layer removes the need for direct references, allowing systems to evolve independently. Brokers may also support features like message persistence, delivery guarantees, topic-based filtering, and asynchronous communication.

In some systems, the observer pattern is used internally to implement subscription mechanisms behind a publish–subscribe interface. In other cases, the patterns are applied independently. For example,JavaScript libraries and frameworks often offer both observer-like subscriptions (e.g., via callback registration) and decoupled pub-sub mechanisms (e.g., via event emitters or signals).^[3][4]

Historically, in early graphical operating systems likeOS/2 andMicrosoft Windows, the terms "publish–subscribe" and "event-driven programming" were often used as synonyms for the observer pattern.^[5]

The observer pattern, as formalized inDesign Patterns,^[1] deliberately omits concerns such as unsubscription, notification filtering, delivery guarantees, and message logging. These advanced capabilities are typically implemented in robust message queuing systems, where the observer pattern may serve as a foundational mechanism but is not sufficient by itself.

Related patterns includemediator andsingleton.

A common drawback of the observer pattern is the potential formemory leaks, known as thelapsed listener problem. This occurs when a subject maintains strong references to its observers, preventing them from beinggarbage collected even if they are no longer needed elsewhere. Because the pattern typically requires both explicit registration and deregistration (as in thedispose pattern), forgetting to unregister observers can leave dangling references. This issue can be mitigated by usingweak references for observer references, allowing the garbage collector to reclaim observer objects that are no longer in use.

In some applications, particularly user interfaces, the subject's state may change so frequently that notifying observers on every change is inefficient or counterproductive. For example, a view that re-renders on every minor change in a data model might become unresponsive or flicker.

In such cases, the observer pattern can be modified to decouple notificationstemporally by introducing a throttling mechanism, such as a timer. Rather than updating on every state change, the observer polls the subject or is notified at regular intervals, rendering an approximate but stable view of the model.

This approach is commonly used for elements likeprogress bars, where the underlying process changes state rapidly. Instead of responding to every minor increment, the observer updates the visual display periodically, improving performance and usability.

This form of temporal decoupling allows observers to remain responsive without being overwhelmed by high-frequency updates, while still reflecting the overall trend or progress of the subject’s state.

In thisUMLclass diagram, theSubject class does not update the state of dependent objects directly. Instead,Subject refers to theObserver interface (update()) for updating state, which makes theSubject independent of how the state of dependent objects is updated. TheObserver1 andObserver2 classes implement theObserver interface by synchronizing their state with subject's state.

TheUMLsequence diagram shows the runtime interactions: TheObserver1 andObserver2 objects callattach(this) onSubject1 to register themselves. Assuming that the state ofSubject1 changes,Subject1 callsnotify() on itself.notify() callsupdate() on the registeredObserver1 andObserver2objects, which request the changed data (getState()) fromSubject1 to update (synchronize) their state.

While the library classesjava.util.Observer andjava.util.Observable exist, they have beendeprecated in Java 9 because the model implemented was quite limited.

Below is an example written inJava that takes keyboard input and handles each input line as an event. When a string is supplied fromSystem.in, the methodnotifyObservers() is then called in order to notify all observers of the event's occurrence, in the form of an invocation of their update methods.

packageorg.wikipedia.examples;importjava.util.ArrayList;importjava.util.List;importjava.util.Scanner;interfaceObserver{voidupdate(Stringevent);}classEventSource{List<Observer>observers=newArrayList<>();publicvoidnotifyObservers(Stringevent){observers.forEach(observer->observer.update(event));}publicvoidaddObserver(Observerobserver){observers.add(observer);}publicvoidscanSystemIn(){Scannerscanner=newScanner(System.in);while(scanner.hasNextLine()){Stringline=scanner.nextLine();notifyObservers(line);}}}publicclassObserverDemo{publicstaticvoidmain(String[]args){System.out.println("Enter Text: ");EventSourceeventSource=newEventSource();eventSource.addObserver(event->System.out.printf("Received response: %s%n",event));eventSource.scanSystemIn();}}

C# provides theIObservable.^[7] andIObserver^[8] interfaces as well as documentation on how to implement the design pattern.^[9]

namespaceWikipedia.Examples;usingSystem;usingSystem.Collections.Generic;classPayload{internalstringMessage{get;init;}}classSubject:IObservable<Payload>{privatereadonlyList<IObserver<Payload>>_observers=new();IDisposableIObservable<Payload>.Subscribe(IObserver<Payload>observer){if(!_observers.Contains(observer)){_observers.Add(observer);}returnnewUnsubscriber(observer,_observers);}internalvoidSendMessage(stringmessage){foreach(IObserver<Payload>observerin_observers){observer.OnNext(newPayload{Message=message});}}}internalclassUnsubscriber:IDisposable{privatereadonlyIObserver<Payload>_observer;privatereadonlyICollection<IObserver<Payload>>_observers;internalUnsubscriber(IObserver<Payload>observer,ICollection<IObserver<Payload>>observers){_observer=observer;_observers=observers;}voidIDisposable.Dispose(){if(_observer!=null&&_observers.Contains(_observer)){_observers.Remove(_observer);}}}internalclassObserver:IObserver<Payload>{privatestring_message;publicvoidOnCompleted(){}publicvoidOnError(Exceptionerror){}publicvoidOnNext(Payloadvalue){_message=value.Message;}internalIDisposableRegister(IObservable<Payload>subject){returnsubject.Subscribe(this);}}

This is a C++23 implementation.

importstd;usingstd::reference_wrapper;usingstd::vector;classSubject;// Forward declaration for usage in ObserverclassObserver{private:// Reference to a Subject object to detach in the destructorSubject&subject;public:explicitObserver(Subject&subj):subject{subj}{subject.attach(*this);}virtual~Observer(){subject.detach(*this);}Observer(constObserver&)=delete;Observer&operator=(constObserver&)=delete;virtualvoidupdate(Subject&s)const=0;};// Subject is the base class for event generationclassSubject{private:vector<RefObserver>observers;public:usingRefObserver=reference_wrapper<constObserver>;// Notify all the attached observersvoidnotify(){for(constObserver&x:observers){x.get().update(*this);}}// Add an observervoidattach(constObserver&observer){observers.push_back(observer);}// Remove an observervoiddetach(Observer&observer){observers.remove_if([&observer](constRefObserver&obj)->bool{return&obj.get()==&observer;});}};// Example of usageclassConcreteObserver:publicObserver{public:explicitConcreteObserver(Subject&subj):Observer(subj){}// Get notificationvoidupdate(Subject&)constoverride{std::println("Got a notification");}};intmain(intargc,char*argv[]){Subjectcs;ConcreteObserverco1(cs);ConcreteObserverco2(cs);cs.notify();}

The program output is:

GotanotificationGotanotification

classEventSource{privateobservers=[]privatenotifyObservers(Stringevent){observers.each{it(event)}}voidaddObserver(observer){observers+=observer}voidscanSystemIn(){varscanner=newScanner(System.in)while(scanner){varline=scanner.nextLine()notifyObservers(line)}}}println'Enter Text: 'vareventSource=newEventSource()eventSource.addObserver{event->println"Received response: $event"}eventSource.scanSystemIn()

importjava.util.ScannertypealiasObserver=(event:String)->Unit;classEventSource{privatevarobservers=mutableListOf<Observer>()privatefunnotifyObservers(event:String){observers.forEach{it(event)}}funaddObserver(observer:Observer){observers+=observer}funscanSystemIn(){valscanner=Scanner(System.`in`)while(scanner.hasNext()){valline=scanner.nextLine()notifyObservers(line)}}}

funmain(arg:List<String>){println("Enter Text: ")valeventSource=EventSource()eventSource.addObserver{event->println("Received response:$event")}eventSource.scanSystemIn()}

usesSystem.Generics.Collections,System.SysUtils;typeIObserver=interface['{0C8F4C5D-1898-4F24-91DA-63F1DD66A692}']procedureUpdate(constAValue:string);end;typeTObserverManager=classprivateFObservers:TList<IObserver>;publicconstructorCreate;overload;destructorDestroy;override;procedureNotifyObservers(constAValue:string);procedureAddObserver(constAObserver:IObserver);procedureUnregisterObserver(constAObserver:IObserver);end;typeTListener=class(TInterfacedObject,IObserver)privateFName:string;publicconstructorCreate(constAName:string);reintroduce;procedureUpdate(constAValue:string);end;procedureTObserverManager.AddObserver(constAObserver:IObserver);beginifnotFObservers.Contains(AObserver)thenFObservers.Add(AObserver);end;beginFreeAndNil(FObservers);inherited;end;procedureTObserverManager.NotifyObservers(constAValue:string);vari:Integer;beginfori:=0toFObservers.Count-1doFObservers[i].Update(AValue);end;procedureTObserverManager.UnregisterObserver(constAObserver:IObserver);beginifFObservers.Contains(AObserver)thenFObservers.Remove(AObserver);end;constructorTListener.Create(constAName:string);begininheritedCreate;FName:=AName;end;procedureTListener.Update(constAValue:string);beginWriteLn(FName+' listener received notification: '+AValue);end;procedureTMyForm.ObserverExampleButtonClick(Sender:TObject);varLDoorNotify:TObserverManager;LListenerHusband:IObserver;LListenerWife:IObserver;beginLDoorNotify:=TObserverManager.Create;tryLListenerHusband:=TListener.Create('Husband');LDoorNotify.AddObserver(LListenerHusband);LListenerWife:=TListener.Create('Wife');LDoorNotify.AddObserver(LListenerWife);LDoorNotify.NotifyObservers('Someone is knocking on the door');finallyFreeAndNil(LDoorNotify);end;end;

Output

Husband listener received notification: Someone is knocking on the doorWife listener received notification: Someone is knocking on the door

A similar example inPython:

fromtypingimportAnyclassSubject:_observers:list[Observer]def__init__(self)->None:self._observers=[]defregister_observer(self,observer:Observer)->None:self._observers.append(observer)defnotify_observers(self,*args:tuple[Any,...],**kwargs:dict[str,Any])->None:forobserverinself._observers:observer.notify(self,*args,**kwargs)classObserver:def__init__(self,subject:Subject)->None:subject.register_observer(self)defnotify(self,subject:Subject,*args:tuple[Any,...],**kwargs:dict[str,Any])->None:print(f"Got{args},{kwargs} from{subject}")subject:Subject=Subject()observer:Observer=Observer(subject)subject.notify_observers("test",kw="python")# prints: Got ('test',) {'kw': 'python'} From <__main__.Observable object at 0x0000019757826FD0>

JavaScript has a deprecatedObject.observe function that was a more accurate implementation of the observer pattern.^[10] This would fire events upon change to the observed object. Without the deprecatedObject.observe function, the pattern may be implemented with more explicit code:^[11]

letSubject={_state:0,_observers:[],add:function(observer){this._observers.push(observer);},getState:function(){returnthis._state;},setState:function(value){this._state=value;for(leti=0;i<this._observers.length;i++){this._observers[i].signal(this);}}};letObserver={signal:function(subject){letcurrentValue=subject.getState();console.log(currentValue);}}Subject.add(Observer);Subject.setState(10);// Output in console.log - 10

• Implicit invocation
• Client–server model
• The observer pattern is often used in theentity–component–system pattern

• Observer implementations in various languages at Wikibooks

• Software design patterns

• Articles with short description
• Short description is different from Wikidata
• Articles with example Java code
• Articles with example Python (programming language) code
• Articles with example C Sharp code