Uploaded 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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    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.