a one-to-many dependency between objects
so that when one object changes state,
all its dependents are notified and updated
• The observer design pattern enables a subscriber to
register with and receive notifications from a provider. It
is suitable for any scenario that requires push-based
• The pattern defines a provider (also known as a subject
or an observable) and zero, one, or more observers.
• Observers register with the provider, and whenever a
predefined condition, event, or state change occurs, the
provider automatically notifies all observers by calling
one of their methods.
• In this method call, the provider can also provide current
state information to observers.
Real Life Metaphor
Some auctions demonstrate this pattern. Each
bidder possesses a numbered paddle that is
used to indicate a bid.
The auctioneer starts the bidding, and
"observes" when a paddle is raised to accept the
The acceptance of the bid changes the bid price
which is broadcast to all of the bidders in the
form of a new bid.
Differentiate between the core (or independent) functionality and
the optional (or dependent) functionality.
Model the independent functionality with a "subject" abstraction.
Model the dependent functionality with an "observer" hierarchy.
The Subject is coupled only to the Observer base class.
The client configures the number and type of Observers.
Observers register themselves with the Subject.
The Subject broadcasts events to all registered Observers.
The Subject may "push" information at the Observers, or, the
Observers may "pull" the information they need from the Subject.
• Subject (IObservable)
– knows its observers. Any number of Observer objects may observe a subject
– provides an interface for attaching and detaching Observer objects.
• Concrete Subject
– stores state of interest to Concrete Observer
– sends a notification to its observers when its state changes
• Observer (IObserver)
– defines an updating interface for objects that should be notified of changes in
• Concrete Observer
– maintains a reference to a Concrete Subject object
– stores state that should stay consistent with the subject's
– implements the Observer updating interface to keep its state consistent with
In the .NET Framework, the observer design
pattern is applied by implementing the generic
The generic type parameter represents the type
that provides notification information.
public interface IObserver<in T>
//Notifies the observer that the provider has finished sending push-based
//Notifies the observer that the provider has experienced an error
//condition. An object that provides additional information about the error.
void OnError(Exception error);
//Provides the observer with new data. The current notification information.
void OnNext(T value);
public interface IObservable<out T>
//Notifies the provider that an observer is to receive notifications.
//The object that is to receive notifications.
//A reference to an interface that allows observers to stop receiving notifications
//before the provider has finished sending them.
IDisposable Subscribe (IObserver <T>observer);
Chain of Responsibility, Command, Mediator, and
Observer, address how you can decouple senders and
receivers, but with different trade-offs.
Chain of Responsibility passes a sender request along a
chain of potential receivers.
Command normally specifies a sender-receiver
connection with a subclass.
Mediator has senders and receivers reference each other
Observer defines a very decoupled interface that allows
for multiple receivers to be configured at run-time.
Have a look at a real world example on TFS:
http://minsk-app-tfs1:8080/ $/CSI - Training
This presentation could not be
The sources of information:
3. Design Patterns: Elements of Reusable Object-oriented
Software, by Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides, 1995 – “Gang of Four”
4. Special Thanks to Denis Sajin for providing the cute cats