1 / 20

The Observer Design Pattern

The Observer Design Pattern. Author : Erich Gamma, et al. Source :Elements of Reusable Object-Oriented Software Speaker : Chiao-Ping Chang Advisor : Ku-Yaw Chang. Outline. Intent Motivation Applicability Structure Consequence Implementation. Intent. The Observer Pattern:

Télécharger la présentation

The Observer Design Pattern

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Observer Design Pattern Author :Erich Gamma, et al. Source :Elements of Reusable Object-Oriented Software Speaker : Chiao-Ping Chang Advisor : Ku-Yaw Chang

  2. Outline • Intent • Motivation • Applicability • Structure • Consequence • Implementation Knowledge Engineering Lab

  3. Intent • The Observer Pattern: • Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Knowledge Engineering Lab

  4. Motivation Knowledge Engineering Lab

  5. Motivation • Data changes in one place, but many other components depend on this data • Separate the presentational aspects from the application data • Application data and presentations can be reused independently Knowledge Engineering Lab

  6. Motivation • Describes how to establish these relationships • The key objects: • Subject and observer in the Observer pattern Knowledge Engineering Lab

  7. Motivation • A subject may have any number of dependent observers • All observers are notified whenever the subject changed its state • Each observer will query the subject to make its state the same with the subject's state Knowledge Engineering Lab

  8. Applicability • When an abstraction has two aspects, one dependent on the other. • 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 notify other objects , and you don’t know who these objects are . Knowledge Engineering Lab

  9. Structure Knowledge Engineering Lab

  10. Structure Knowledge Engineering Lab

  11. Demo example Knowledge Engineering Lab

  12. Consequences • Reuse subjects (observers) without reusing their observers (subjects) • Add observers without modifying the subject or other observers Knowledge Engineering Lab

  13. Consequences • Further benefits and liabilities : • Abstract coupling between Subject and Observer. • Support for broadcast communication • The notification is broadcast automatically to all interested objects • Up to the observer to handle or ignore a notification • Unexpected updates • The simple update protocol provides no details on whatchanged in the subject Knowledge Engineering Lab

  14. Implementation • Observing more than one subject. • Extend the Update interface to let the observer know which subject is sending the notification • The subject can pass itself as a parameter • Dangling references to deleted subjects • Notify its observers to reset their reference to it Knowledge Engineering Lab

  15. Implementation • Who triggers the update? • Have state-setting operations on Subject call Notify after they change the subject's state • Advantage :Clients don't have to remember to call Notify on the subject • Disadvantage :Cause several consecutive updates, which may be inefficient Knowledge Engineering Lab

  16. Implementation • Who triggers the update? • Make clients responsible for calling Notify at the right time • Advantage :Avoiding needless intermediate updates • Disadvantage :Clients might forget to call Notify • Avoiding observer-specific update protocols: the push and pull models Knowledge Engineering Lab

  17. Implementation • The push model: • The subject sends all changed data when it notifies the observers • Assumes subjects know something about their observers' needs • The pull model: • The subject only sends minimal information when sending a change notification • Emphasizes the subject's ignorance of its observers Knowledge Engineering Lab

  18. Implementation • The push model: • Less reusable • Assumptions might not always be true • When the observers need the subject information most of the time • The pull model: • Inefficient • Observer classes must ascertain what changed without help from the Subject. • When observers can decide if and when they need a specific piece of information Knowledge Engineering Lab

  19. The Publisher-Subscriber Pattern • Source:Pattern-Oriented Software Architecture  • The Publisher-Subscriber Pattern: • One publisher notifies any number of subscribers about changes to its state. • The key objects: • Publisher and subscriber in the Publisher-Subscriber pattern Knowledge Engineering Lab

  20. Thanks! Knowledge Engineering Lab

More Related