Editing Observer pattern (section)

==Overview==

The observer design pattern is a behavioural pattern listed among the 23 well-known [[Design Patterns|"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.<ref name="GoF">{{cite book|author=Erich Gamma|url=https://archive.org/details/designpatternsel00gamm/page/293|title=Design Patterns: Elements of Reusable Object-Oriented Software|last2=Richard Helm|last3=Ralph Johnson|last4=John Vlissides|publisher=Addison Wesley|year=1994|isbn=0-201-63361-2|pages=[https://archive.org/details/designpatternsel00gamm/page/293 293ff]|url-access=registration}}</ref>

The observer pattern addresses the following problems:<ref>{{cite web |title=Observer Design Pattern |url=https://www.geeksforgeeks.org/observer-pattern-set-1-introduction/ |access-date= |website=www.geeksforgeeks.org}}</ref>
* 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.

Defining a one-to-many dependency between objects by defining one object (subject) that updates the state of dependent objects directly is inflexible because it couples the subject to particular dependent objects. However, it might be applicable from a performance point of view or if the object implementation is tightly coupled (such as low-level kernel structures that execute thousands of times per second). Tightly coupled objects can be difficult to implement in some scenarios and are not easily reused because they refer to and are aware of many objects with different interfaces. In other scenarios, tightly coupled objects can be a better option because the compiler is able to detect errors at compile time and optimize the code at the CPU instruction level.

* Define <code>Subject</code> and <code>Observer</code> objects.
* When a subject changes state, all registered observers are notified and updated automatically (and probably asynchronously).

The sole responsibility of a subject is to maintain a list of observers and to notify them of state changes by calling their <code>update()</code> operation. 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 their state with the subject's state) when they are notified. This makes subject and observers loosely coupled. Subject and observers have no explicit knowledge of each other. Observers can be added and removed independently at run time. This notification-registration interaction is also known as [[publish-subscribe]].