The Observer Design Pattern Presented By: Manali Joshi

1. The Observer Design PatternPresented By:Manali Joshi Manali Joshi

2. Intent The Observer Pattern defines a one-to-many dependency between a subject object and any number of observer objects so that when the subject object changes state, all its dependents are notified and updated automatically Also Known As : Dependents, Publish-Subscribe Manali Joshi

3. Motivation • Partitioning a system into a collection of co-operating classes requires maintaining consistency between related objects • Achieving such consistency by making tightly-coupled classes reduces their re-usability • Two parts to the Observer Pattern • Subject • Observer • Relationship between subject and observer is one-to-many; it needs to be de-coupled to make the subject and observer independently reusable. Manali Joshi

4. Example Spreadsheet Program Manali Joshi

5. Applicability Use the Observer Pattern when… • The abstraction has two aspects with one dependent on another • The subject object does not know exactly how many observer objects it has • Subject object should be able to notify it’s observer objects without knowing who these observer objects are i.e. the objects need to be de-coupled Manali Joshi

6. Structure Manali Joshi

7. Participants • Subject • Knows its observers • Can have any number of observers • Provides an interface for attaching and detaching observer objects • Observer • Defines an update interface for objects that should be notified of changes in subject • Concrete Subject • Store state of interest for concrete observer objects • Send notification to observer objects when state changes • Concrete Observer • Maintains reference to Concrete Subject object • Stores state that should be consistent with the subject’s state • Implement update operation Manali Joshi

8. Collaborations • Concrete Subject notifies its observers whenever a change occurs that could make it’s observers’ state inconsistent with it’s own • After this, a Concrete Observer may query the subject for information and then change it’s internal state accordingly Manali Joshi

9. Implementation Issues • Mapping subjects to their observers: a subject can keep track of it’s list of observers as observer reference or in a hash table • Observing more than one subject: In some cases it may make sense to have a many-to-many relationship between subjects and observers. The Update interface in the observer has to know which subject is sending the notification • Who triggers the Update: 2 options – state setting operation in the subject to trigger notify or Observer to trigger notify Manali Joshi

10. Implementation Issues contd. .. • Dangling references to deleted subjects: Deleting a subject or observer should not produce dangling references. Subjects should notify observers so that they may reset their references. Observers also cannot be simple deleted as other subjects may be observing them • Make sure that subject state is self-consistent before notification: else an observer may query the intermediate state • Specifying modifications of interest explicitly: Observer could be registered only for specific events Manali Joshi

11. Consequences • Abstract coupling between subject and observer:Subjects know that they have a list of observers each conforming to a simple interface of the abstract Observer class. Subject has no knowledge of the concrete class of any observer. Thus, coupling between subject and observer is abstract and minimal. As there is no tight coupling, each can be extended and reused individually. • Dynamic relationship between subject and observer:can be established at runtime giving programming flexibility • Support for broadcast communication:A notification is broadcast automatically to all interested objects that are subscribed to a subject. • Unexpected Updates:Observers have no knowledge about each other and are blind to the cost of changing the subject. A seemingly innocuous operation on the subject may cause a series of updates in the observers and their dependent objects. With a dynamic relation between the subject and the observer, the update dependency may be hard to track down. Manali Joshi

12. Related Patterns • Mediator: Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. • Singleton: Ensure a class only has one instance, and provide a global point of access to it. Manali Joshi

13. References • http://www.wohnklo.de/patterns/observer.html • http://sern.ucalgary.ca/courses/SENG/609.04/W98/lamsh/observerLib.html • http://page.inf.fu-berlin.de/~bokowski/Observer.html Manali Joshi

14. Questions Manali Joshi