• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Design patterns
 

Design patterns

on

  • 165 views

 

Statistics

Views

Total Views
165
Views on SlideShare
150
Embed Views
15

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 15

http://practices.issoft.by 15

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Design patterns Design patterns Presentation Transcript

    • Design Patterns Observer Written by: Andrey Stakhievich, Automation Department, Coherent Solutions
    • 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.
    • 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.
    • 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.
    • Check List 1. Differentiate between the core (or independent) functionality and the optional (or dependent) functionality. 2. Model the independent functionality with a "subject" abstraction. 3. Model the dependent functionality with an "observer" hierarchy. 4. The Subject is coupled only to the Observer base class. 5. The client configures the number and type of Observers. 6. Observers register themselves with the Subject. 7. The Subject broadcasts events to all registered Observers. 8. The Subject may "push" information at the Observers, or, the Observers may "pull" the information they need from the Subject.
    • UML Diagram
    • 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
    • .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.
    • 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); }
    • 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); }
    • 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.
    • The end…
    • 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