Editing Observer pattern (section)

== Coupling and typical publish-subscribe implementations ==
 
Typically, the observer pattern is implemented so that the subject being observed is part of the object for which state changes are being observed (and communicated to the observers). This type of implementation is considered [[Coupling (computer programming)|tightly coupled]], forcing both the observers and the subject to be aware of each other and have access to their internal parts, creating possible issues of [[scalability]], speed, message recovery and maintenance (also called event or notification loss), the lack of flexibility in conditional dispersion and possible hindrance to desired security measures. In some ([[polling (computer science)|non-polling]]) implementations of the [[publish-subscribe pattern]], this is solved by creating a dedicated message queue server (and sometimes an extra message handler object) as an extra stage between the observer and the object being observed, thus decoupling the components. In these cases, the message queue server is accessed by the observers with the observer pattern, subscribing to certain messages and knowing (or not knowing, in some cases) about only the expected message, while knowing nothing about the message sender itself; the sender may also know nothing about the observers. Other implementations of the publish-subscribe pattern, which achieve a similar effect of notification and communication to interested parties, do not use the observer pattern.<ref>[https://github.com/millermedeiros/js-signals/wiki/Comparison-between-different-Observer-Pattern-implementations Comparison between different observer pattern implementations] Moshe Bindler, 2015 (Github)</ref><ref>[https://www.safaribooksonline.com/library/view/learning-javascript-design/9781449334840/ch09s05.html Differences between pub/sub and observer pattern] The Observer Pattern by Adi Osmani (Safari books online)</ref> 

In early implementations of multi-window operating systems such as [[OS/2]] and [[Microsoft Windows|Windows]], the terms "publish-subscribe pattern" and "event-driven software development" were used as synonyms for the observer pattern.<ref>[https://books.google.com/books?id=18wFKrkDdM0C&pg=PA230&lpg=PA230 The Windows Programming Experience] [[Charles Petzold]], Nov 10, 1992, [[PC Magazine]] ([[Google Books]])</ref> 

The observer pattern, as described in the ''Design Patterns'' book, is a very basic concept and does not address removing interest in changes to the observed subject or special logic to be performed by the observed subject before or after notifying the observers. The pattern also does not deal with recording change notifications or guaranteeing that they are received. These concerns are typically handled in message-queueing systems, in which the observer pattern plays only a small part. 

Related patterns include publish–subscribe, [[mediator pattern|mediator]] and [[singleton pattern|singleton]].

===Uncoupled===
The observer pattern may be used in the absence of publish-subscribe, as when model status is frequently updated. Frequent updates may cause the view to become unresponsive (e.g., by invoking many [[painter's algorithm|repaint]] calls); such observers should instead use a timer. Instead of becoming overloaded by change message, the observer will cause the view to represent the approximate state of the model at a regular interval. This mode of observer is particularly useful for [[progress bar|progress bars]], in which the underlying operation's progress changes frequently.