The document discusses the observer design pattern, which defines a one-to-many dependency between objects so that when one object changes state, all its dependent objects are notified automatically. It describes observers registering with providers to receive notifications of predefined events or state changes. When such an event occurs, the provider notifies all observers by calling one of their methods and can provide current state information. Real-life examples of auctions are provided, where bidders observe changes in bid price. Implementation in .NET using IObservable and IObserver interfaces is also summarized.

1. Design Patterns
Observer
Written by: Andrey Stakhievich,
Automation Department,
Coherent Solutions

2. Definition
Observer defines:
a one-to-many dependency between objects
so that when one object changes state,
all its dependents are notified and updated
automatically.

3. Description
• 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
notification.
• 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.

4. 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
bid.
The acceptance of the bid changes the bid price
which is broadcast to all of the bidders in the
form of a new bid.

5. Check List
1.
2.
3.
4.
5.
6.
7.
8.
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.

6. UML Diagram

7. Entities
• 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
a subject.
• 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
the subject's

8. .Net Implementation
In the .NET Framework, the observer design
pattern is applied by implementing the generic
System.IObservable<T> and
System.IObserver<T> interfaces.
The generic type parameter represents the type
that provides notification information.

9. IObserver
public interface IObserver<in T>
{
//Notifies the observer that the provider has finished sending push-based
//notifications.
void OnCompleted();
//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);
}

10. IObservable
public interface IObservable<out T>
{
//Summary:
//Notifies the provider that an observer is to receive notifications.
//
//Parameters:
//observer:
//The object that is to receive notifications.
//
//Returns:
//A reference to an interface that allows observers to stop receiving notifications
//before the provider has finished sending them.
IDisposable Subscribe (IObserver <T>observer);
}

11. Final Comparison
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
indirectly.
Observer defines a very decoupled interface that allows
for multiple receivers to be configured at run-time.

12. THE END…
Have a look at a real world example on TFS:
http://minsk-app-tfs1:8080/ $/CSI - Training
Center/Clients/Automation/OOP/DP/Observer/

13. But..
This presentation could not be
completed without…
The sources of information:
1. http://www.dofactory.com/Patterns/PatternObserver.aspx
2. http://www.vincehuston.org/dp/observer.html
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