Observer Method 1. References Gamma Erich, Helm Richard, “Design Patterns: Elements of Reusable Object- Oriented Software” 2.

Slides:



Advertisements
Similar presentations
Design Patterns.
Advertisements

 Recent researches show that predicative programming can be used to specify OO concepts including classes, objects, interfaces, methods, single and multiple.
The Observer Pattern SE-2811 Dr. Mark L. Hornick 1.
Figures – Chapter 7.
Design Patterns Pepper. Find Patterns Gang of Four created 23 Siemens published another good set x
Chapter 7 – Object-Oriented Design
CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.1 Software Engineering: Analysis and Design - CSE3308 Patterns CSE3308/CSC3080/DMS/2000/12.
The Bridge Pattern.. Intent Decouple an abstraction from its implementation so that the two can vary independently Also known as: Handle/Body.
Spring 2010ACS-3913 Ron McFadyen1 Weather Station Page 39+ In this application, weather station devices supply data to a weather data object. As the data.
Reza Gorgan Mohammadi AmirKabir University of Technology, Department of Computer Engineering & Information Technology Advanced design.
Observer Pattern Fall 2005 OOPD John Anthony. What is a Pattern? “Each pattern describes a problem which occurs over and over again in our environment,
Observer Pattern Tu Nguyen. General Purpose When one object changes state, all the dependent objects are notified and updated. Allows for consistency.
Iterators T.J. Niglio Computer & Systems Engineering Fall 2003 Software Design & Documentation Object Behavioral.
CSE Software Engineering: Analysis and Design, 2002Lecture 7B.1 Software Engineering: Analysis and Design - CSE3308 Patterns CSE3308/DMS/2002/15.
BehavioralCmpE196G1 Behavioral Patterns Chain of Responsibility (requests through a chain of candidates) Command (encapsulates a request) Interpreter (grammar.
March Ron McFadyen1 Design Patterns In software engineering, a design pattern is a generally repeatable solution to a commonly-occurring problem.
Copyright © Active Frameworks Inc. - All Rights Reserved.More On Behavioral Patterns - Page L9-1 PS95&96-MEF-L16-1 Dr. M.E. Fayad Creationa l.
ECE 355 Design Patterns Tutorial Part 2 (based on slides by Ali Razavi) Presented by Igor Ivković
PRESENTED BY SANGEETA MEHTA EECS810 UNIVERSITY OF KANSAS OCTOBER 2008 Design Patterns.
Behavioral Patterns  Behavioral patterns are patterns whose purpose is to facilitate the work of algorithmic calculations and communication between classes.
Design Patterns.
Concordia University Department of Computer Science and Software Engineering Click to edit Master title style ADVANCED PROGRAM DESIGN WITH C++ Model View.
02 - Behavioral Design Patterns – 2 Moshe Fresko Bar-Ilan University תשס"ח 2008.
Case Studies on Design Patterns Design Refinements Examples.
Design Patterns Lecture III. What Is A Pattern? Current use comes from the work of the architect Christopher Alexander Alexander studied ways to improve.
Design Patterns Part two. Structural Patterns Concerned with how classes and objects are composed to form larger structures Concerned with how classes.
Observer Behavioral Pattern. Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.
Programming in C# Observer Design Pattern
Behavioral Pattern: Observer C h a p t e r 5 – P a g e 186 A large monolithic design does not scale well as additional graphical and monitoring requirements.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns VII Observer, Command, and Memento.
Behavioral Design Patterns Morteza Yousefi University Of Science & Technology Of Mazandaran 1of 27Behavioral Design Patterns.
Where Do Surrogates Fit into This Proxy Pattern Observer Pattern Visitor Pattern By Kurt Rehwinkel.
Team 6 “The Unparseables” Design Patterns Chain of Responsibility Observer Flyweight 1.
Factory Method Explained. Intent  Define an interface for creating an object, but let subclasses decide which class to instantiate.  Factory Method.
Proxy, Observer, Symbolic Links Rebecca Chernoff.
Behavioural Design Patterns Quote du jour: ECE450S – Software Engineering II I have not failed. I've just found 10,000 ways that won't work. - Thomas Edison.
Linzhang Wang Dept. of Computer Sci&Tech, Nanjing University The Strategy Pattern.
Design Pattern. Definition: A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
OBSERVER DESIGN PATTERN. Behavioral Patterns  Behavioral patterns are those patterns that are most specifically concerned with communication between.
Manali Joshi1 The Observer Design Pattern Presented By: Manali Joshi.
Model View Controller Architectural Pattern and Observer Pattern
Behavioral Patterns1 Nour El Kadri SEG 3202 Software Design and Architecture Notes based on U of T Design Patterns class.
BEHAVIORAL PATTERNS 13-Sep-2012 Presenters Sanjeeb Kumar Nanda & Shankar Gogada.
Concordia University Department of Computer Science and Software Engineering Click to edit Master title style ADVANCED PROGRAMMING PRACTICES Model View.
The State Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
Chapter 8 Object Design Reuse and Patterns. More Patterns Abstract Factory: Provide manufacturer independence Builder: Hide a complex creation process.
The Observer Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
Slide design: Dr. Mark L. Hornick
OBSERVER PATTERN OBSERVER PATTERN Presented By Presented By Ajeet Tripathi ISE
The Observer Design Pattern Author :Erich Gamma, et al. Source :Elements of Reusable Object-Oriented Software Speaker : Chiao-Ping Chang Advisor : Ku-Yaw.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
February 23, 2009Observer Pattern, OOA&D, Rubal Gupta, CSPP, Winter ‘09 Observer Pattern Defines a “one-to-many” dependency between objects so that when.
Software Architecture and Design BITS C461/IS C341 Software Engineering First Semester Aditya P. Mathur Department of Computer Science Purdue.
Design Patterns: MORE Examples
Slide design: Dr. Mark L. Hornick
A Brief Introduction to Design Patterns
Observer Design Pattern
Observer Design Pattern
Presented by Igor Ivković
Design Patterns - A few examples
Advanced Program Design with C++
Observer Pattern 1.
Design pattern Lecture 9.
Introduction to Design Patterns
Advanced ProgramMING Practices
Design Patterns Lecture part 1.
8. Observer Pattern SE2811 Software Component Design
Advanced ProgramMING Practices
Presented by Igor Ivković
Software Design Lecture : 40.
Presentation transcript:

Observer Method 1

References Gamma Erich, Helm Richard, “Design Patterns: Elements of Reusable Object- Oriented Software” 2

Background Intent - Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Also known as - Dependents, Publish- Subscribe 3

Motivation (1) A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects. You don't want to achieve consistency by making the classes tightly coupled, because that reduces their reusability. 4

Motivation (2) This behavior implies that the spreadsheet and charts (observers) are dependent on the data object (subject) and therefore should be notified of any change in the latter’s state to keep the observers consistent with the subject. The key objects in this pattern are subject and observers. 5

Structure Subject - Knows its observers. Any number of Observer objects may observe a subject. - Provides an interface for attaching and detaching Observer objects. ConcreteSubject -Stores state of interest to ConcreteObserver objects. -Sends a notification to its observers when its state changes. Observer - Defines an (updating) interface for objects that should be notified of changes in a subject. ConcreteObserver -Maintains a reference to a ConcreteSubject object. -Stores state that should stay consistent with the subject's. -Implements the Observer interface to keep its state consistent with the subject's. 6

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. [NHM: a change manager can take care of which observers to change] – 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. 7

Collaborations (1) 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. – [NHM: Note: This gives the “observer” the control as to whether and when it wants to update.] – [NHM: Alternative implementation could be to update the observer immediately upon change to the “subject” (i.e., upon notification by subject to observer – no need for observer to query the subject for information). – Here, the concrete subject could return a ‘Struct’ type variable containing: (a) notification about the update and (b) the new values to be updated.] 8

Collaborations (2) Observer object initiates the change request. Notification from the subject to observers (in a loop or recursive call). – notify need not always be called by the subject. It can be called by an observer or by another kind of object entirely. Each observer gets the latest state of the subject, and the observer is updated. 9

Consequences The Observer pattern lets you vary subjects and observers independently. You can reuse subjects without reusing their observers, and vice versa. It lets you add observers without modifying the subject or other observers. Further benefits of the Observer pattern Abstract coupling between Subject and Observer (loose coupling) – All a subject knows is that it has a list of observers, each conforming to the simple interface of the abstract Observer class. The subject doesn’t know the concrete class of any observer. Thus the coupling between subjects and observers is abstract and minimal. 10

Consequences../cont’d Benefits: Support for broadcast communication. – The notification that a subject sends out to observers needn’t specify its receiver. – The notification is broadcast automatically to all interested objects that subscribed to it. – The subject doesn’t care how many interested objects exist; its only responsibility is to notify its observers. – This gives you the freedom to add and remove observers at any time. – It’s up to the observer to handle or ignore a notification. 11

Consequences Limitation of the Observer pattern Unexpected updates – Consider many (very many) observers. Should there be a change in the subject, all observers subscribed to that subject get notified to update. – However, observers are independent of each other and do not know who and how many other observers are there – that will need to be updated when the subject changes. – Thus the cost and time needed for update can be unpredictable. 12

Implementation (1) Several issues related to the implementation of the dependency mechanism can be considered here. Issue 1: Mapping subjects to their observers. The simplest way for a subject to keep track of the observers it should notify is to store references to them explicitly in the subject. However, such storage may be too expensive when there are many subjects and few observers. Solution: One solution is to trade space for time by using an associative look-up (e.g., a hash table) to maintain the subject-to- observer mapping. Thus a subject with no observers does not incur storage overhead. On the other hand, this approach increases the cost of accessing the observers. 13

Implementation (2) Issue 2: Observing more than one subject. It might make sense in some situations for an observer to depend on more than one subject. For example, a spreadsheet may depend on more than one data source. It's necessary to extend the Update interface in such cases to let the observer know which subject is sending the notification. Solution: The subject can simply pass itself as a parameter in the Update operation, thereby letting the observer know which subject to examine. 14

Implementation (3) Issue 3: Dangling references to deleted subjects. Deleting a subject should not produce dangling references in its observers. Solution: One way to avoid dangling references is to make the subject notify its observers as it is deleted so that they can reset their reference to it. In general, simply deleting the observers is not an option, because other objects may reference them, or they may be observing other subjects as well. 15

Implementation (4) Issue 4: Encapsulating complex update semantics. When the dependency relationship between subjects and observers is particularly complex, an object that maintains these relationships might be required. We call such an object a ChangeManager. Its purpose is to minimize the work required to make observers reflect a change in their subject. For example, if an operation involves changes to several interdependent subjects, you might have to ensure that their observers are notified only after all the subjects have been modified to avoid notifying observers more than once. ChangeManager has three responsibilities: It maps a subject to its observers and provides an interface to maintain this mapping. This eliminates the need for subjects to maintain references to their observers and vice versa. It defines a particular update strategy. It updates all dependent observers at the request of a subject. 16

Implementation (5) The several independent Subjects can have one ChangeManager The ChangeManager is responsible for ensuring that their observers are notified only after all the subjects have been modified to avoid notifying observers more than once. 17

Sample code (1) An abstract class defines the Observer interface. class Subject; class Observer { public: virtual ~ Observer(); virtual void Update(Subject* theChangedSubject) = 0; protected: Observer(); }; This is an abstract class that defines the functionalities of an observer. theChangedSubject variable is the shared variable between the Subject and the Observers(see slide 7). The Subject class is responsible for changing the value of the variable theChangedSubject and notifying the Observer classes about the change. In the beginning when the code is not being executed, the variable theChangedSubject is initialized to 0 in the Observer classes. Whenever there is a change in the value for the variable theChangedSubject in the Subject class, the Observers will also change the value for the variable. 18 This portion of the code explains the Constructor of the Observer class. This is a situation when you have more than one subject and you have to pass which subject it is as a parameter (see slide 15)

Sample code (2) This implementation supports multiple subjects for each observer. The subject passed to the Update operation lets the observer determine which subject changed when it observes more than one. Similarly, an abstract class defines the Subject interface: class Subject { public: virtual ~Subject(); virtual void Attach(Observer*); virtual void Detach(Observer*); virtual void Notify(); protected: Subject(); private: List *_observers; }; void Subject::Attach (Observer* o) { _observers->Append(o); } void Subject::Detach (Observer* o) { _observers->Remove(o); } void Subject::Notify () { ListIterator i(_observers); for (i.First(); !i.IsDone(); i.Next()) { i.CurrentItem()->Update(this); } This is an abstract class that defines the functionalities of a subject. These three methods Attach(), Detach() and Notify() are the basic functionalities of all Subject classes in the slide 7. This portion of the code shows the dependency relationship between the Subject and the Observer classes in the slide 7. One Subject can have multiple Observers and the Observer objects are stored in a List<> Type variable. 19 This code shows one Observer is changing the value of the shared variable at a time. (Sequentially as per their order in the List<>.