1. March 200592.3913 Ron McFadyen1 Observer 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. Text examples: A user interface object, a window, needs to be informed when a domain object changes Alarm systems need notification of alarms being triggered

2. March 200592.3913 Ron McFadyen2 Observer Pattern 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

3. March 200592.3913 Ron McFadyen3 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 Observer Pattern Example

4. March 200592.3913 Ron McFadyen4 Example: Suppose our class model is: DepartmentRegOffice Course * Faculty 0,1* 0..*

5. March 200592.3913 Ron McFadyen5 Filling out some methods Department RegOffice Course * 0..* update() Attach() Detach() Notify() checkFull() myObs 0,1 Instructor 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()

6. March 200592.3913 Ron McFadyen6 Course > Observer * The subject is loosely coupled to a set of observers; Course will have a set of references to observers. FacultyRegOffice Faculty and RegOffice must implement the Observer interface > Subject

7. March 200592.3913 Ron McFadyen7 Example: interactions i:Facultyc: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)

8. March 200592.3913 Ron McFadyen8 Example: interactions c:CoursemyObs: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

9. March 200592.3913 Ron McFadyen9 Suppose c:Course becomes full … update() sent to every observer – the following shows how the 3 object collaborate i:Facultyc:Courser:RegOffice 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

10. March 200592.3913 Ron McFadyen10 Suppose c:Course becomes full … update() sent to every observer – the following shows how c:Course interacts with an arbitrary set of observers c:CoursemyObs:Object * : update() [full] notify() checkFull() The course realizes it is full, and notifies its observers In general, the course sends the update message to every object that is registered for the event

11. March 200592.3913 Ron McFadyen11 Observer Pattern 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) … subject is loosely coupled to observers Don’t need to modify the Subject if the set of observers changes More detail needed if the subscribers need to get specific information after being notified

12. March 200592.3913 Ron McFadyen12 Objects that participate in the observer pattern must either be publishers (subject) or subscribers (observers) Publishers / subject publish events of interest to others notify objects, who previously subscribed, when events occur subscribers / observers subscribe to information about these events these objects must be allowed to unsubscribe

13. March 200592.3913 Ron McFadyen13 Publishers must have Attach method (Larman text: addPropertyListener) Detach method Notify method (Larman text: publishPropertyEvent) Subscribers must have Update method (Larman text: onPropertyEvent) Also known as Publish-Subscribe

14. March 200592.3913 Ron McFadyen14 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.

15. March 200592.3913 Ron McFadyen15 Figure from text - 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

16. March 200592.3913 Ron McFadyen16 Figure from text - The Observer Pattern in a DCD

17. March 200592.3913 Ron McFadyen17 Figure from text - a window subscribing When a SaleFrame1 (the subscriber) is initialized, it subscribes to the Sale (the publisher)

18. March 200592.3913 Ron McFadyen18 Figure from text - 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

19. March 200592.3913 Ron McFadyen19 Figure from text - 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