Your SlideShare is downloading. ×
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply



Published on

Object-oriented analysis and design(OOAD) and Design Pattern Slides UML Slides. for more slides refer

Object-oriented analysis and design(OOAD) and Design Pattern Slides UML Slides. for more slides refer

Published in: Education, Technology, Business

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. OBSERVER The Observer defines a one to many relationship, so that when one object changes state, the others are notified and updated automatically. 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
  • 2.
    • Intent
    •   Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
    •   Alternative Name:
    •   Dependents, Publish-Subscribe
    Problem: How to handle a common side-effect (i.e. need to maintain consistency between related object)of partitioning a system into a collection of cooperating classes with out making the classes tightly coupled , - which in turn makes classes less reusable.
  • 3. Illustration a=50% b=30% c=20% e.t.c Subject Change notification Request, modification
  • 4.
    • Solution:
    • The observer pattern describes how to establish these relationships.
    • The key objects in this pattern are subject and observer.
      • A subject may have any number of dependent observer.
      • All observers are notified whenever the subject undergoes a change in state.
      • In response, each observer will query the subject to synchronize its state with the subject’s state.
  • 5. Applicability
    • Use the Observer pattern in any of the following situations:
    • When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.
    • When a change to one object requires changing others, and you don’t know how many objects need to be changed.
    • When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don’t want these objects tightly coupled.
  • 6. Structure } *
  • 7. Collaborations
    •    ConcreteSubject notifies its observers whenever a change occurs that could make its observers’ state inconsistent with its own.
    • After being informed of a change in the concrete subject, a ConcreteObserver object may query the subject for information. ConcreteObserver uses this information to reconcile its state with that of the subject.
  • 8. Collaborations NOTE: How observer object that initiates the change request postpones its update until it gets a notification form the subject.
  • 9. Consequences
    • Abstract coupling between Subject and Observer
    • Support for broadcast communication.
    • Unexpected updates.
  • 10. Model
  • 11. Related patterns
    • Mediator: By encapsulating complex update semantics, the ChangeManager acts as mediator between subjects and observers.
    • Singleton: The ChangeManager may use the Singleton pattern to make it unique and globally accessible.