Transcript Week 3 notes

Observer Pattern
Keeping An Eye on Things
Need to introduce
observer pattern formally
first, include book
definition & design principle
Situation
 WeatherData object pulls data
from a weather station
 Multiple ways we want to display
the data
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
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?
Loose Coupling
 When objects interact without
having knowledge of each other
 Why is this good?
 How does observer ensure that
the coupling is loose?
Let’s Look at the WeatherStation Code
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?
How does the Observer
Know what information
has changed?
Pull
 The Subject tells the observer
“something changed”
 the Observer is responsible for
calling getters to get the
information it wants
Push
 When the subject notifies the
observer, it puts the
information that changed into
the message
Observer In Java
Is-a vs. Has-A again!
Observer Pattern
<<interface>>
Subject
registerObserver()
removeObserver()
notifyObservers()
1
*
<<interface>>
Observer
update()
ConcreteObserver
ConcreteSubject
getState()
setState()
Observer Pattern in
Java
Observable
addObserver()
deleteObserver()
notifyObservers()
setChanged()
ConcreteSubject
getState()
setState()
1
*
<<interface>>
Observer
update(Observable o, Object arg)
ConcreteObserver
Observable
 Java’s version of Subject
 Keeps track of all of the
observers and notification for
you
 It’s a CLASS!
Java WeatherStation
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?
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
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
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
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