1. Observer Pattern Keeping An Eye on Things Need to introduce observer pattern formally first, include book definition & design principle Keeping An Eye on Things Need to introduce observer pattern formally first, include book definition & design principle

2. Situation  WeatherData object pulls data from a weather station  Multiple ways we want to display the data  WeatherData object pulls data from a weather station  Multiple ways we want to display the data

3. What is WeatherData?  Initial Source Provided by Customer  Their code will call measurementsChanged any time the data changes  We can modify MeasurementsChanged and add new methods, but we can’t change anything else  Initial Source Provided by Customer  Their code will call measurementsChanged any time the data changes  We can modify MeasurementsChanged and add new methods, but we can’t change anything else

4. Design Thoughts  What’s Changing?  So let’s make a class for each display  We could make MeasurementsChanged call each display, but what’s wrong with that?  What’s Changing?  So let’s make a class for each display  We could make MeasurementsChanged call each display, but what’s wrong with that?

5. Loose Coupling  When objects interact without having knowledge of each other  Why is this good?  How does observer ensure that the coupling is loose?  When objects interact without having knowledge of each other  Why is this good?  How does observer ensure that the coupling is loose?

6. Let’s Look at the WeatherStation Code

7. Questions We Should Ponder...  Why do the observers have a reference to their subject?  What changes if they want us to add another type of display?  Why does the book have the DisplayElement interface?  Our update method is not loosely coupled (why?). What would be better?  Why do the observers have a reference to their subject?  What changes if they want us to add another type of display?  Why does the book have the DisplayElement interface?  Our update method is not loosely coupled (why?). What would be better?

8. How does the Observer Know what information has changed?

9. Pull  The Subject tells the observer “something changed”  the Observer is responsible for calling getters to get the information it wants  The Subject tells the observer “something changed”  the Observer is responsible for calling getters to get the information it wants

10. Push  When the subject notifies the observer, it puts the information that changed into the message

11. Observer In Java Is-a vs. Has-A again!

12. Observer Pattern > Subject registerObserver() removeObserver() notifyObservers() ConcreteSubject getState() setState() > Observer update() ConcreteObserver 1*

13. Observer Pattern in Java Observable addObserver() deleteObserver() notifyObservers() setChanged() ConcreteSubject getState() setState() > Observer update(Observable o, Object arg) ConcreteObserver 1*

14. Observable  Java’s version of Subject  Keeps track of all of the observers and notification for you  It’s a CLASS!  Java’s version of Subject  Keeps track of all of the observers and notification for you  It’s a CLASS!

15. Java WeatherStation

16. setChanged()  Tells Observable that the state of the instance has changed  notifyObservers() will only notify them if the state has changed  Why would they do that?  Tells Observable that the state of the instance has changed  notifyObservers() will only notify them if the state has changed  Why would they do that?

17. if (newTemp != currTemp) { currTemp = newTemp; setChanged(); } if (newHumidity != currHumidity) { currHumidity = newHumidity; setChanged(); } if (newPressure != currPressure) { currPressure = newPressure; setChanged(); } notifyObservers(); We can make many changes to the state and only call notifyObservers() Once. Update() is only called if something really changed

18. Pull in Java  notifyObservers() takes no parameters  Update(Observable o, Object arg)  o is reference to the subject observer can use to get the pieces of state it needs  arg is null  notifyObservers() takes no parameters  Update(Observable o, Object arg)  o is reference to the subject observer can use to get the pieces of state it needs  arg is null

19. Push in Java  notifyObservers(Object arg)  Update(Observable o, Object arg)  o is a reference to the subject causing the update  arg is the message from the subject  notifyObservers(Object arg)  Update(Observable o, Object arg)  o is a reference to the subject causing the update  arg is the message from the subject

20. Observable is a class  But can only have one super class  Can we contain a subject?  Nope - they protected notifyObservers  If you have a parent, implement it like we did earlier  But can only have one super class  Can we contain a subject?  Nope - they protected notifyObservers  If you have a parent, implement it like we did earlier