nov 200391.3913 ron mcfadyen1 observer p. 368+ problem: there are many objects (subscribers) needing...
Post on 20-Dec-2015
220 views
TRANSCRIPT
Nov 2003 91.3913 Ron McFadyen 1
Observer P. 368+
Problem: There are many objects (subscribers) needing to know of the state changes, or events, of another object (publisher), and we want to keep the coupling low.
Solution: Define a subscriber or listener interface that is implemented by the subscribers.
Situations:
•Text example: A user interface object, a window, needs to be informed when a domain object changes
•In some distributed meta-data environments, replicas need to be notified when the source changes
•Alarm systems need notification of alarms being triggered
Also known as Publish-Subscribe
Nov 2003 91.3913 Ron McFadyen 2
Figure 23.20 the display must reflect the correct total
There is a requirement for a window to be updated whenever the total value of the sale changes
Nov 2003 91.3913 Ron McFadyen 3
Observer
Text example.
There is a requirement for a window to be updated whenever the total of the sale changes
A subscriber interface, PropertyListener, is defined.
SaleFrame1 is defined to inherit the PropertyListener interface. This will allow SaleFrame1 to be alerted of changes in the value of the sale total
A reference to the Sale is passed to SaleFrame1 when SaleFrame1 is initialized. This allows SaleFrame1 to subscribe to the Sale instance
The Sale only knows of objects that subscribe to it; it does not know what class of object they are - so, coupling is kept low.
Nov 2003 91.3913 Ron McFadyen 4
Figure 23.21 The Observer Pattern in a DCD
Sale is a publisher and needs to be able to attach observers (addPropertyListener) and notify (via publishPropertyEvent message) its observers when an event of interest occurs
SaleFrame1 is an observer; it needs to be updated when an event of interest occurs (it will receive an onPropertyEvent message)
Nov 2003 91.3913 Ron McFadyen 5
Figure 23.22 a window subscribing
When a SaleFrame1 (the subscriber) is initialized, it subscribes to the Sale (the publisher)
Nov 2003 91.3913 Ron McFadyen 6
Figure 23.23 a sale publishing a change
A Sale receives a message changing its state. The Sale invokes its method, publishPropertyEvent, which will in turn notify any subscribers of the change
Note the activations for the sale
Nov 2003 91.3913 Ron McFadyen 7
Figure 23.24 a window receiving notification
The window receives notification of the state change and modifies its display appropriately
Notice that this is a continuation from the previous sequence diagram
Nov 2003 91.3913 Ron McFadyen 8
Observer Pattern Example
From: Designed Patterns Explained by Shalloway & Trott; Addison-Wesley; P 265-277
Observers: objects that want to be notified of a certain event. It must have an update method whereby it is notified of an event.
Subject: the object that triggers the event. It must implement:
attach (observer) - add an observer to its list of observers
detach (observer) - remove an observer from …
notify () - goes through its list of observers calling each observer’s update method
various methods to allow an observer to get additional information
The Observer Pattern defines a one to many dependency between objects so that when one object changes state, all its dependents are notified automatically
Nov 2003 91.3913 Ron McFadyen 9
Observer Pattern Example
Whenever a new customer is entered
• send a welcome letter
• verify the customer’s address with the post office
• send letter with coupons to new customers within 20 miles of the company’s “brick and mortar” stores.
Four classes from the problem domain: Customer, WelcomeLetter, AddrVerification, BrickAndMortar
Applying the Observer pattern results in Customer being the Subject; the others will be Observers
Altogether: 6 classes
Nov 2003 91.3913 Ron McFadyen 10
Class Diagram
Customer
+attach()+detach()+notifyobs()+getState()+setState()
Observer+update()
WelcomeLetter
AddrVerification
BrickAndMortar
Subject
+attach()+detach+notifyobs()
Nov 2003 91.3913 Ron McFadyen 11
Observer Pattern
Example: a special situation for courses is: when enrollment reaches the capacity and no more seats are available, the course is full. (for simplicity we ignore sections)
Suppose when a course is full:
•The instructor is informed.
•The Registration Office is informed
Nov 2003 91.3913 Ron McFadyen 12
Example: Suppose our class model is:
Department RegOffice
Course*
Faculty0,1 *
0..*
Nov 2003 91.3913 Ron McFadyen 13
Example: Filling out some methods
Department
RegOffice
Course*
0..*update()
Attach()
Detach()
Notify()
checkFull()
myObs
0,1Instructor
Faculty and RegOffice will be observers, and must implement the update method
Course will be the subject, and will implement attach, detach, and notify methods. Course keeps track of its observers.
0..*
Faculty
update()
Nov 2003 91.3913 Ron McFadyen 14
Course
<<interface>>Observer
*
Recall from Larman that the subject is loosely couple to a set of observers; Course will have a set of references to observers.
Faculty RegOffice
Faculty and RegOffice must implement the Observer interface
Nov 2003 91.3913 Ron McFadyen 15
Example: interactions
i:Faculty c:Course
When the Instructor is assigned to a course, the Instructor must register his/her interest with the course
attach(i)assign(c)
myObs:Object
The course adds the Instructor to its list
add(i)
Nov 2003 91.3913 Ron McFadyen 16
Example: interactions
c:Course myObs:Object
The Registration Office registers its interest in the course
add(r)
r:RegOffice
attach(r)newCourse(c)
The course adds the Registration Office to its list
Nov 2003 91.3913 Ron McFadyen 17
Example: interactions – updates sent to two observers
i:Faculty c:Courser:RegOffice
update()
update()
[full] notify()checkFull()
The course realizes it is full, and notifies its two observers
The two objects will do whatever is appropriate for them when they are notified via the update message
Nov 2003 91.3913 Ron McFadyen 18
Example: interactions – similar to previous slide, but in more general terms
c:Course myObs:Object
* : update()
[full] notify()checkFull()
The course realizes it is full, and notifies its observers
In general, the course sends the update message to each object that is registered for the event
Nov 2003 91.3913 Ron McFadyen 19
Observer Pattern
Summary/Review
Responsibility for monitoring an event is with the object that creates the event (the Subject)
Subject knows its observers (but not the class they belong to)
Don’t need to modify the Subject if the observers change
More detail needed if the subscribers need to get specific information after being notified
Nov 2003 91.3913 Ron McFadyen 20
Objects that participate in the observer pattern must either be publishers (subject) or subscribers (observers)
publishers
•publish events of interest to others
•notify objects, who previously subscribed, when events occur
subscribers
•subscribe to information about these events
•these objects must be allowed to unsubscribe