Transcript Observerx

Observer
Please Snarf the Code for Today’s Class.
Today you will
• Implement the observer pattern on some
sample code
• Hear about a few more general issues with the
observer pattern
• Take a look at Tivoo Part 3
The WeatherData example
• Go to “Head First Design Patterns Observer” in
the resources section of Sakai, and read the
problem description (pages 38-41)
• Then take a look at the WeatherData class in
the code you’ve snarfed. Come to a
consensus with those sitting next to you about
what’s wrong with it. You should be able to
find at least 2 things.
What’s wrong with the WeatherData
class? (more than one may apply)
1. The class handles two things: communicating
with the remote weather station and dealing
with the GUI
2. WeatherData is a data class
3. Duplicated code in the
measurementsChanged method
4. This code is not “closed” in the situation
where new kinds of weather displays are
added
What We Want
• Code for handling the model to be separate
from code focused on displaying the data
• But there’s a problem: oftentimes displays
need to be updated when the model changes
• So the model code needs to call the display
code
• So the model code needs to know about the
display code
Solution
• So the model code needs to call the display code
• So the model code needs to know about the display code
• The model code allows other code to register it’s interest in
updates (we say it allows Observers to register themselves)
• Then the display code registers…this happens in the man or
someplace outside of the model
• Whenever a change happens, the model notifies all its
observers
• The key insight here is that although the model knows
something probably receives updates, it does not care what
kind of classes do that. So it is “open” to any new kind of
observer
We want the classes to look like this
(but keep the existing functionality)
• Go ahead and submit your code via Ambient
Observer in General
Not just in GUIs
• Anyplace where you want notifications of
what happens, but want to decouple the code
that notifies from the code that acts on the
notifications
Push vs. Pull
• “Push” – the subject passes a lot of data about
what has changed to it’s observers. Makes it
easier for observers.
• “Pull” – the subject just notifies the observers
and then they query subject (or other state) to
figure out how they ought to change. Allows
subjects to be more generic.
Be Aware
• Java has built-in observer objects for you to
subclass from (java.util.Observable and
java.util.Observer). They take of the drudge
work of implementing observers. (HFDP pg.
64)
• But don’t confuse the idea (pattern) of
observer with Java’s implementation. Even
when there’s a built in one, you’ll often want
to roll your own.
Limits of Observers
• When you have many data objects, all of
which can be observed it can get difficult to
set up the appropriate observer relationships
• Occasionally the observer pattern can be used
with data too – one part of the model is
updated when another part changes. Be
careful with this – you can get infinite update
loops or other problems