Observer Pattern

2 the Observer Pattern
h
Keeping your g
g
Objects in the know
Hey Jerry, I’m
notifying everyone that the
Patterns Group meeting moved to
Saturday night. We’re going to be
talking about the Observer Pattern.
That pattern is the best! It’s the
BEST, Jerry!
Don’t miss out when something interesting happens! We’ve got a

pattern that keeps your objects in the know when something they might care about happens.
Objects can even decide at runtime whether they want to be kept informed. The Observer
Pattern is one of the most heavily used patterns in the JDK, and it’s incredibly useful. Before
we’re done, we’ll also look at one to many relationships and loose coupling (yeah, that’s right,
we said coupling). With Observer, you’ll be the life of the Patterns Party.
weather monitoring station
Congratulations!
Your team has just won the contract to build

Weather-O-Rama, Inc.’s next generation,
Internet-based Weather Monitoring Station.
Inc.
-O-Rama,
Weather
Street
100 Main 45021
Alley, OK
Tornado
rk
nt of Wo
St ate m e e xt genera
tion
d o u r n
to buil
s o n b e in g selected tation!
Congratu
lation itoring S
W e a ther Mon t pending
Internet-b
a s e d
d o n our paten itions
ti o n w il l be b a s e
e n t w e a ther cond
er sta ks cur r ʼd like
The weath object, which trac etric pressure). We ee
ata om thr
WeatherD , humidity, and bar it ia ll y provides
re tha t in and a
(temperatu ate an application w e a th e r statistics
for you to
cre ditions, therData
m e n ts : c urrent con al time as the Wea
e
display ele st, all updated in r asurements.
f o r e c a e n t me
simple e most rec er-O-
je c t a c q u ir e s th
th e r s ta ti on. Weath an
ob ble wea lopers c
th is is a n expanda I so that other deve ht in. Weʼd
Further, to release
an AP them rig
m a w a n ts d is p la y s and plug
Ra er
own weath at API!
write their supp th ly e ss model:
once
r y o u to a t b u s in
like fo
ks we hav
e a gre for each
a th in to c h a rge them
-R a m te n d to pay
Weather-O s are hooked, we in part: we are going
er est
the custom use. Now for the b
e y
display th options. lp ha applica
tion.
s to c k n a n d a
you in ur desig
r w a r d to seeing yo
o
We look f
,
Sincerely
s to you.
u r r ic a ne, CEO e r D a ta source file
Johnny H the Wea th
e a r e o v ernighting
P.S. W
Chapter 2
the observer pattern
The Weather Monitoring application over view

The three players in the system are the weather station (the physical device that
acquires the actual weather data), the WeatherData object (that tracks the data coming
from the Weather Station and updates the displays), and the display that shows users
ions is one of
Current Conditt displays. The
the current weather conditions.
three differen t weather stats

user can also ge.
and a forecast
Humidity displays
pulls data Current
sensor device Conditions
Temp: 72°
Humidity: 60
Pressure:
Temperature
sensor device WeatherData
object
Weather Station
Display device
Pressure
sensor device
Weather-O-Rama provides What we implement
The WeatherData object knows how to talk to the physical Weather Station, to get
updated data. The WeatherData object then updates its displays for the three different
display elements: Current Conditions (shows temperature, humidity, and pressure),
Weather Statistics, and a simple forecast.
Our job, if we choose to accept it, is to create an app that

uses the WeatherData object to update three displays for
current conditions, weather stats, and a forecast.
weather data class
Unpacking the WeatherData class

As promised, the next morning the WeatherData source files arrive.
Peeking inside the code, things look pretty straightforward:
t
n t h e m ost recenmidity
retur e, hu
WeatherData
e t h r e e methods s for temperatur
Thes measurement respectively.
getTemperature() weather metric pressure s a r
e
e set; th d
b a r o ia b le e
getHumidity() and se var pdat
’t c a r e HOW the ows how to get u
getPressure() n
We do Data object k tation. n
Weather the Weather S
measurementsChanged()
info from
// other methods
/*
* This method gets called
* whenever the weather measurements
* have been updated
*
rData
of the Weathe */
The developers a clue about what we public void measurementsChanged() {
object left us // Your code goes here
need to add... }
Remember, this Current Co WeatherData.java

ONE of three different disnditions is just
play screens.
Current
Conditions Our job is to implement measurementsChanged()
Temp: 72° so that it updates the three displays for current
Humidity: 60 conditions, weather stats, and forecast.
Pressure:
Display device
What do we know so far ?

The spec from Weather-O-Rama wasn’t all that clear, but we have to
figure out what we need to do. So, what do we know so far?
getTemperature()
R The WeatherData class has getter methods for three
getHumidity()
measurement values: temperature, humidity and
barometric pressure. getPressure()
R The measurementsChanged() method is called any

measurementsChanged()
time new weather measurement data is available. (We
don’t know or care how this method is called; we just
know that it is.)
Weather
Stats
Avg. temp: 62°
Min. temp: 50°
Max. temp: 78°
Current
Conditions
R We need to implement three display elements that Temp: 72°
Humidity: 60
use the weather data: a current conditions display, a Pressure:
Display Two
statistics display and a forecast display. These displays
must be updated each time WeatherData has new
Forecast
measurements. Display One
TT
T
Display Three
R The system must be expandable—other developers
?
can create new custom display elements and users
can add or remove as many display elements as they
want to the application. Currently, we know about
only the initial three display types (current conditions,
statistics and forecast).
Future displays
first try with the weather station
Taking a first, misguided SWAG at

the Weather Station
Here’s a first implementation possibility—we’ll take the hint from the Weather-O-
Rama developers and add our code to the measurementsChanged() method:
public class WeatherData {
// instance variable declarations
public void measurementsChanged() {

Grab the most recent measuremets
float temp = getTemperature(); by calling the WeatherData’s getter
float humidity = getHumidity(); methods (already implemented).
float pressure = getPressure();
currentConditionsDisplay.update(temp, humidity, pressure);

statisticsDisplay.update(temp, humidity, pressure); Now update
forecastDisplay.update(temp, humidity, pressure); the displays...
}
Call each display element
// other WeatherData methods here update its display, passing to
} most recent measurements.it the
What’s wrong with our implementation?

Think back to all those Chapter 1 concepts and principles...
float temp = getTemperature();

float humidity = getHumidity(); Area of change, we need
float pressure = getPressure(); to encapsulate this.
currentConditionsDisplay.update(temp, humidity, pressure);
statisticsDisplay.update(temp, humidity, pressure);
forecastDisplay.update(temp, humidity, pressure);
}
At least we seem to be using a

common interface to talk to the
display elements... they all have an
By coding to concrete implementations update() method takes the temp,
we have no way to add or remove humidity, and pressure values.
other display elements without making
changes to the program.
Umm, I know I’m new

here, but given that we are in
the Observer Pattern chapter,
maybe we should start using it?
We’ll take a look at

Observer, then come
back and figure out how
to apply it to the weather
monitoring app.
meet the observer pattern
Meet the Obser ver Pattern

You know how newspaper or magazine
subscriptions work:
1 A newspaper publisher goes into business and begins

publishing newspapers.
2 You subscribe to a particular publisher, and every time

there’s a new edition it gets delivered to you. As long as
you remain a subscriber, you get new newspapers.
3 You unsubscribe when you don’t want papers anymore,

and they stop being delivered.
4 While the publisher remains in business, people, hotels,

airlines and other businesses constantly subscribe and
unsubscribe to the newspaper.
Publishers + Subscribers = Observer Pattern

If you understand newspaper subscriptions, you pretty much
understand the Observer Pattern, only we call the publisher
the SUBJECT and the subscribers the OBSERVERS.
Let’s take a closer look:
The observers have subscribed to

(registered with) the Subject
to receive updates when the
Subject’s data changes.
When data in the Su bject changes,
fied.
the observers are noti
t manages
Subject objecdata. 2 Dog Obje
ct
some bit of
2
2
Su int
Cat Object
bje 2
ct Obje
ct
New data values are

communicated to the t
observers in some form Mo ec
use Obj
when they change. Observer Objects
an
This object isn’tdoesn’t
observer, so it
the
Duck Obje
ct get notified whechnanges.
Subject’s data
A day in the life of the Obser ver Pattern
ct
” Dog Obje
me 2
e
rib
bsc Su int
A Duck object comes along u bje
/s ct Obje
ct
ter Cat Object
and tells the Subject that is
eg
it wants to become an “r
observer. t
Mo ec
use Obj
t
Duck really wants in on the Duck Obj ec
Observers
action; those ints Subject is
sending out whenever its state
changes look pretty interesting...
The Duck object is now an 2

ct
official observer. Dog Obje
Su int
bje
ct Obje
ct
Duck is psyched... he’s on the

list and is waiting with great ct
Duck Obje Cat Object
anticipation for the next
notification so he can get an int.
t
Mo ec
use Obj
Observers
8 8
The Subject gets a new 8 ct
Dog Obje
data value! Su int 8
bje
ct Obje
ct
8
Now Duck and all the rest of the ct
observers get a notification that
the Subject has changed.
t
Mo ec
use Obj
Observers
8
ct
Dog Obje
Su int
The Mouse object asks to be bje
ct Obje
ct
“re
removed as an observer. mo
ve
/u ct
ns Duck Obje Cat Object
The Mouse object has been ub
sc
getting ints for ages and is tired rib
em
of it, so it decides it’s time to e”
stop being an observer. Mo ec
t
use Obj
Observers
8
ct
Dog Obje
Su int
Mouse is outta here! bje
ct Obje
ct
The Subject acknowledges the ct

Mouse’s request and removes it
from the set of observers.
t
Mo ec
use Obj
Observers
The Subject has another 14 14

new int. 14 Dog Obje
ct
Su int 14
All the observers get another bje
ct Obje
ct
notification, except for the

Mouse who is no longer included. ct
Don’t tell anyone, but the Mouse
secretly misses those ints...
maybe it’ll ask to be an observer
t
again some day. Mo
use Obj
ec
Observers
The Obser ver Pattern defined

When you’re trying to picture the Observer Pattern, a newspaper
subscription service with its publisher and subscribers is a good
way to visualize the pattern.
In the real world however, you’ll typically see the Observer Pattern
defined like this:
The Observer Pattern defines a one-to-many

dependency between objects so that when one
object changes state, all of its dependents are
notified and updated automatically.
The Observer Pattern
defines a one-to-many
Let’s relate this definition to how we’ve been talking about the relationship between a set
pattern:
of objects.
ONE TO MANY RELATIONSHIP
Object that When the state of one
holds state
object changes, all of its
8 8
8 Dog Obje
ct
dependents are notified.
Su int 8
Objects
bje
ct Obje
ct
8
ct
t
Dependen
t
Mo ec
use Obj
Automatic update/notification Observers
The subject and observers define the one-to-many relationship.

The observers are dependent on the subject such that when the
subject’s state changes, the observers get notified. Depending on
the style of notification, the observer may also be updated with
new values.
As you’ll discover, there are a few different ways to implement
the Observer Pattern but most revolve around a class design that
includes Subject and Observer interfaces.
Let’s take a look...
loose coupling
The Obser ver Pattern defined:

rvers need
the class diagram All potential obsee Observer
to implement ths interface
interface. Thi hod, update(),
c t i n t erface.o register Each subject just has one metd when the
e t can have many that gets callee changes.
he Subj erface
Here’s tts use this intlso to removers. observers. Subject’s stat
Objec ervers and a eing observe
as obs elves from b
thems
<<interface>> observers <<interface>>
Subject Observer
registerObserver() update()
removeObserver()
notifyObservers()
subject
ConcreteSubject ConcreteObserver
registerObserver() {...} update()
removeObserver() {...} // other Observer specific
ways
A concrete subjectbjalect notifyObservers() {...} methods
Su
implements the tion to
interface. In addiremove
getState()
the register and rete subject

setState()
methods, the concfyObservers() Concrete observers can be

implements a noti ed to update ect may
method that is us servers The concrete subj s for any class that implements the
all the current ob anges. also have methottd ing its state Observer interface. Each
whenever state ch setting and ge is later). observer registers with a concrete
(more about th subject to receive updates.
The power of Loose Coupling

When two objects are loosely coupled, they can interact,
but have very little knowledge of each other.
The Observer Pattern provides an object design where

subjects and observers are loosely coupled.
Why?
The only thing the subject knows about an observer is that it

implements a certain interface (the Observer interface). It doesn’t need to
know the concrete class of the observer, what it does, or anything else about it.
We can add new observers at any time. Because the only thing the subject
depends on is a list of objects that implement the Observer interface, we can add new
observers whenever we want. In fact, we can replace any observer at runtime with
another observer and the subject will keep purring along. Likewise, we can remove
How many
observers at any time.
different kindsyou
We never need to modify the subject to add new types of observers. Let’s of change can
say we have a new concrete class come along that needs to be an observer. We don’t identify here?
need to make any changes to the subject to accommodate the new class type, all
we have to do is implement the Observer interface in the new class and register as
an observer. The subject doesn’t care; it will deliver notifications to any object that
implements the Observer interface.
We can reuse subjects or observers independently of each other. If we
have another use for a subject or an observer, we can easily reuse them because the
two aren’t tightly coupled.
Changes to either the subject or an observer will not affect the other.
Because the two are loosely coupled, we are free to make changes to either, as long as
the objects still meet their obligations to implement the subject or observer interfaces.
Design Principle
Strive for loosely coupled designs
between objects that interact.
Loosely coupled designs allow us to build flexible OO

systems that can handle change because they minimize
the interdependency between objects.
Designing the Weather Station
Let’s also create an

mponents interface for all display
All our weatherOco erver elements to implement. The
i n t erface, implement the s bs display elements just need to
ur subj
e c t
iliar. gives the
interface. Thi on
Here’s oould look fam interface implement a display() method.
Subject a commn it comes time
this sh to talk to whe observers.
to update the
<<interface>> observers <<interface>> <<interface>>
Subject Observer DisplayElement
registerObserver() update() display()
removeObserver()
notifyObservers()
CurrentConditionsDisplay
update()
jec t ThirdPartyDisplay
sub display() { // display current
WeatherData update()
measurements }
registerObserver() display() { // display
removeObserver() something else based on
notifyObservers() measurements }
StatisticsDisplay
This display element update()
getTemperature()
shows the current display() { // display the aver-
Developers
getHumidity()
measurements from th
WeatherData object. e
age, min and max measure-
can implement
getPressure()
measurementsChanged() ments }
the Observer
and Display
ForecastDisplay interfaces to
This one keeps track create their own
WeatherData now
update()
of the min/avg/max display element.
implements the
display() { // display the
measurements and
Subject interface.
forecast }
displays them.
This display shows the weat her

forecast based on th e ba ro meter.
These three display elements should have a pointer to

WeatherData labeled “subject” too, but boy would
this diagram start to look like spaghetti if they did.
Implementing the Weather Station

We’re going to start our implementation using the class diagram and following Mary
and Sue’s lead (from a few pages back). You’ll see later in this chapter that Java
provides some built-in support for the Observer pattern, however, we’re going to get
our hands dirty and roll our own for now. While in some cases you can make use of
Java’s built-in support, in a lot of cases it’s more flexible to build your own (and it’s
not all that hard). So, let’s get started with the interfaces:
Both of these methods take an

public interface Subject { Observer as an argument; that is, the
public void registerObserver(Observer o);
public void removeObserver(Observer o);
Observer to be registered or removed.
public void notifyObservers();
} This method is called to notify all observers
when the Subject’s state has changed.
public interface Observer { The Observer interface is
public void update(float temp, float humidity, float pressure); implemented by all observers,
} so they all have to implement
These are the state values the Observers get from the update() method. Here
the Subject when a weather measurement changes we’re following Mary and
Sue’s lead and passing the
public interface DisplayElement { measurements to the observers.
public void display();
} The DisplayElement interface just includes
one method, display(), that we will call when
the display element needs to be displayed.
implementing the weather station
Implementing the Subject interface in

WeatherData
Remember our first attempt at implementing the WeatherData class at the
beginning of the chapter? You might want to refresh your memory. Now
it’s time to go back and do things with the Observer Pattern in mind...
public class WeatherData implements Subject { WeatherData now implements

private ArrayList observers; the Subject interface.
private float temperature;
to
We’ve added an ArrayList
private float humidity;
private float pressure;
hold the Ob ser ver s, and we
or.
public WeatherData() { create it in the construct
observers = new ArrayList();
}
When an observer registers, we just
public void registerObserver(Observer o) { add it to the end of the list.
Here we implement the Subject Interface.
observers.add(o);
}
Likewise, when an observer wants to un-register,
public void removeObserver(Observer o) { we just take it off the list.
int i = observers.indexOf(o);
if (i >= 0) {
Here’s the fun part; this is where we
tell all the observers about the state.
observers.remove(i);
}
} Because they are all Observers, we
know they all implement update(), so
public void notifyObservers() { we know how to notify them.
for (int i = 0; i < observers.size(); i++) {
Observer observer = (Observer)observers.get(i);
observer.update(temperature, humidity, pressure);
Observers whtens
}
} ify the
We not measuremen
we get updateaedther Station.
from the W
notifyObservers();
}
public void setMeasurements(float temperature, float humidity, float pressure) {

this.temperature = temperature;
this.humidity = humidity; Okay, while we wanted to ship a nice little
this.pressure = pressure; weather station with each book, the publisher
measurementsChanged();
wouldn’t go for it. So, rather than reading
}
actual weather data off a device, we’re
// other WeatherData methods here going to use this method to test our display
} elements. Or, for fun, you could write code
to grab measurements off the web.
Now, let’s build those display elements

Now that we’ve got our WeatherData class straightened out, it’s time to build the
Display Elements. Weather-O-Rama ordered three: the current conditions display, the
statistics display and the forecast display. Let’s take a look at the current conditions
display; once you have a good feel for this display element, check out the statistics and
forecast displays in the head first code directory. You’ll see they are very similar.
It also imp
p le m e n
er
ts Observhe because ourleAments DisplayElement,
y im t require all d PI is going to
This dispnlaget changes from
c a
so it Data object. implement thisplay elements to
is interface.
Weather
public class CurrentConditionsDisplay implements Observer, DisplayElement {
private float temperature;
private float humidity;
private Subject weatherData; tor is passed The construc the
weatherData object (the Subject)
and we use it to register the
public CurrentConditionsDisplay(Subject weatherData) {
this.weatherData = weatherData;
weatherData.registerObserver(this); display as an observer.
}
public void update(float temperature, float humidity, float pressure) {

When update() is called, we

this.humidity = humidity;
save the temp and humidity

display();
}
and call display().
public void display() {
System.out.println(“Current conditions: “ + temperature
display() method
+ “F degrees and “ + humidity + “% humidity”);
The
just prints out the mostty.
}
recent temp and humidi

}
testing the weather station
Power up the Weather Station

1 First, let’s create a test harness
The Weather Station is ready to go, all we need is some code to glue
everything together. Here’s our first attempt. We’ll come back later in
the book and make sure all the components are easily pluggable via a
configuration file. For now here’s how it all works:
the
First, creaattea
public class WeatherStation { WeatherD
public static void main(String[] args) { object.
WeatherData weatherData = new WeatherData();
If you don’t CurrentConditionsDisplay currentDisplay =

want to new CurrentConditionsDisplay(weatherData);
download the StatisticsDisplay statisticsDisplay = new StatisticsDisplay(weatherData);
code, you can ForecastDisplay forecastDisplay = new ForecastDisplay(weatherData);
comment out
these two lines Create the three
weatherData.setMeasurements(80, 65, 30.4f);
weatherData.setMeasurements(82, 70, 29.2f);
and run it. weatherData.setMeasurements(78, 90, 29.2f); displays and
} pass them the
WeatherData object.
}
Simulate new weather
measurements.
2 Run the code and let the Observer Pattern do its magic
File Edit Window Help StormyWeather
%java WeatherStation
Current conditions: 80.0F degrees and 65.0% humidity
Avg/Max/Min temperature = 80.0/80.0/80.0
Forecast: Improving weather on the way!
Forecast: Watch out for cooler, rainy weather
Forecast: More of the same
%
java’s built-in observer pattern
Using Java’s built-in

Observer Pattern With Java’s built-in
So far we’ve rolled our own code for the support, all you have to do is
Observer Pattern, but Java has built-in support extend Observable and tell it
in several of its APIs. The most general is the when to notify the Observers.
Observer interface and the Observable class in The API does the rest for you.
the java.util package. These are quite similar
to our Subject and Observer interface, but give
you a lot of functionality out of the box. You
can also implement either a push or pull style of
update to your observers, as you will see.
To get a high level feel for java.util.Observer and
java.util.Observable, check out this reworked
OO design for the WeatherStation:
le class keeps familiar. In s

The Observallbyour observers This should loaok ly the same a
track of a s them for you. fact, it’s ex clctass diagram !
and notifie our previous We left out the
DisplayElement
<<interface>> interface, but all
the displays still
observers
Observable Observer
Observable is a addObserver() update()
implement it too.
CLASS not an deleteObserver()
interface, so notifyObservers()
WeatherData setChanged()
extends Observable. sub

jec
t GeneralDisplay StatisticsDisplay ForecastDisplay
update() update() update()
display() display() display()
WeatherData
’t look
getTemperature()
d o e s n getHumidity()
This liar! Hold to getPressure()
to make to the update()
fami , we’ll get There will be a few changesser s, but basically it’s
tight n a sec... method in the concrete Obcomvermon Observer interface,
this i ich we can the same idea... we have a t’s
Here’s our Subject,Obwh able. We called by the Subject.
rv
now also call the gistseer(), remove() with an update() method tha
don’t need the reers() methods
and notifyObserv t that behavior
anymore; we inheriss.
from the supercla
How Java’s built-in Obser ver Pattern works

The built in Observer Pattern works a bit differently than the implementation that we used
on the Weather Station. The most obvious difference is that WeatherData (our subject)
now extends the Observable class and inherits the add, delete and notify Observer methods
(among a few others). Here’s how we use Java’s version:
For an Object to become an observer...

As usual, implement the Observer interface (this time the java.util.Observer
interface) and call addObserver() on any Observable object. Likewise, to remove
yourself as an observer just call deleteObserver().
For the Observable to send notifications...

First of all you need to be Observable by extending the java.util.Observable
superclass. From there it is a two step process:
1 You first must call the setChanged() method to signify

that the state has changed in your object
akes an
This versiondatta object
arbitrary assed to
that gets pver when it
2 Then, call one of two notifyObservers() methods:
each Obser
either notifyObservers() or notifyObservers(Object arg) is notified.
For an Observer to receive notifications...

It implements the update method, as before, but the signature of the
method is a bit different: data object
update(Observable o, Object arg)
The Subject that sent

the notification is passed This will be the data object that was
in as this argument. passed to notifyObservers(), or null if
a data object wasn’t specified.
If you want to “push” data to the observers you can pass the data as a data object
to the notifyObserver(arg) method. If not, then the Observer has to “pull” the data
it wants from the Observable object passed to it. How? Let’s rework the Weather
Station and you’ll see.
behind the scenes
Wait, before we get

to that, why do we need this
setChanged() method? We didn’t
need that before.
The setChanged() method is used to signify that the state has changed and that notifyObservers(),
when it is called, should update its observers. If notifyObservers() is called without first calling
setChanged(), the observers will NOT be notified. Let’s take a look behind the scenes of
Observable to see how this works:
Behind
the Scenes
setChanged() { The setChanged() method ue.

}
changed = true
sets a changed flag to tr
e f o r the notifyObservers(Object arg) {

notifyObservers() onlyif
ocod lass. if (changed) {
notifies its observers UE.
Pseudervable C
the changed flag is TR
for every observer on the list {
Obs call update (this, arg)
}
changed = false And after it notifies
} the observers, it sets the
} changed flag back to false.
notifyObservers() {
notifyObservers(null)
}
Why is this necessary? The setChanged() method is meant to give you more flexibility in how
you update observers by allowing you to optimize the notifications. For example, in our weather
station, imagine if our measurements were so sensitive that the temperature readings were
constantly fluctuating by a few tenths of a degree. That might cause the WeatherData object
to send out notifications constantly. Instead, we might want to send out notifications only if the
temperature changes more than half a degree and we could call setChanged() only after that
happened.
You might not use this functionality very often, but it’s there if you need it. In either case, you
need to call setChanged() for notifications to work. If this functionality is something that is useful
to you, you may also want to use the clearChanged() method, which sets the changed state back to
false, and the hasChanged() method, which tells you the current state of the changed flag.
Reworking the Weather Station with the built-in support
First, let’s rework WeatherData to use

java.util.Observable
1 Make sure we are importing the 2 3 We don’t need to keep track of

right Observer/Observable. our observers anymore, or manage
We are now
subclassing Observable. their registration and removal,
(the superclass will handle that)
import java.util.Observable; so we’ve removed the code for
import java.util.Observer; register, add and notify.
public class WeatherData extends Observable {
private float temperature; 4 Our constructor no longer
private float humidity; needs to create a data
private float pressure; structure to hold Observers.
* Notice we aren’t sending a data object with

public WeatherData() { }
public void measurementsChanged() { the notifyObservers() call. That means

setChanged(); we’re using the PULL model.
}
notifyObservers(); *
public void setMeasurements(float temperature, float humidity, float pressure) {
this.humidity = humidity;
this.pressure = pressure; 5 We now first call setChanged() to
measurementsChanged(); indicate the state has changed
} before calling notifyObservers().
public float getTemperature() {
return temperature;
}
public float getHumidity() {

return humidity;
These methods aren’t new, but

}
6
public float getPressure() { because we are going to use “pull”
return pressure; we thought we’d remind you
} they are here. The Observers
} will use them to get at the
WeatherData object’s state.
current conditions rework
Now, let’s rework the CurrentConditionsDisplay
1 Again, make sure we are importing

the right Observer/Observable.
2 We now are implementing the Observer interface from java.util.

import java.util.Observable;
import java.util.Observer;
public class CurrentConditionsDisplay implements Observer, DisplayElement {

Observable observable;
private float temperature; 3 Our constructor now takes an
private float humidity; Observable and we use this to
add the current conditions
public CurrentConditionsDisplay(Observable observable) { object as an Observer.
this.observable = observable;
observable.addObserver(this);
}
4 We’ve changed the
public void update(Observable obs, Object arg) {
update() method
if (obs instanceof WeatherData) {
WeatherData weatherData = (WeatherData)obs;
to take both an
this.temperature = weatherData.getTemperature(); Observable and the
this.humidity = weatherData.getHumidity(); optional data argument.
display();
}
}
public void display() {

System.out.println(“Current conditions: “ + temperature 5 In update(), we first
+ “F degrees and “ + humidity + “% humidity”); make sure the observable
} is of type WeatherData
} and then we use its
getter methods to
obtain the temperature
and humidity
measurements. After
that we call display().
Code Magnets
The ForecastDisplay class is all scrambled up on the fridge. Can you
Exercise reconstruct the code snippets to make it work? Some of the curly
braces fell on the floor and they were too small to pick up, so feel
free to add as many of those as you need!
ble
serva
Ob
ay(
Displ
t
cas
Fore {
lic )
pub rvable display();
s e
ob
observable.add
Observer(this)
;
if (observable instanceof WeatherData) {
implements
public class ForecastDisplay
Observer, DisplayElement {
{
display()
public void y code here
// displa
}
e();
sur e; Pr essur
s t
tPre a.ge
cu rren therDat
e = wea
P ressur sure =
last entPres
curr
private floa
t currentPre
private floa ssure = 29.9
t lastPressu 2f;
re;
WeatherData we
atherData =
(WeatherData)o
bservable;
le,
ble observab
ic void update(Observa
publ
{
Object arg)
servable;
import java.util.Ob
til.Ob server;
import java.u
you are here 4 69

test drive
Running the new code

Just to be sure, let’s run the new code...
File Edit Window Help TryTihisAtHome
%java WeatherStation
Forecast: Improving weather on the way!
Forecast: Watch out for cooler, rainy weather
Forecast: More of the same
%
Hmm, do you notice anything different? Look again...

You’ll see all the same calculations, but mysteriously, the order of the text output is
different. Why might this happen? Think for a minute before reading on...
Never depend on order of evaluation of the

Observer notifications
The java.util.Observable has implemented its notifyObservers() method such that the
Observers are notified in a different order than our own implementation. Who’s right?
Neither; we just chose to implement things in different ways.
What would be incorrect, however, is if we wrote our code to depend on a specific

notification order. Why? Because if you need to change Observable/Observer
implementations, the order of notification could change and your application would
produce incorrect results. Now that’s definitely not what we’d consider loosely coupled.
Doesn’t
java.util.Observable
violate our OO design principle
of programming to interfaces
not implementations?
The dark side of java.util.Obser vable

Yes, good catch. As you’ve noticed, Observable is a class, not an interface, and worse,
it doesn’t even implement an interface. Unfortunately, the java.util.Observable
implementation has a number of problems that limit its usefulness and reuse. That’s not
to say it doesn’t provide some utility, but there are some large potholes to watch out for.
Observable is a class
You already know from our principles this is a bad idea, but what harm does it really
cause?
First, because Observable is a class, you have to subclass it. That means you can’t add
on the Observable behavior to an existing class that already extends another superclass.
This limits its reuse potential (and isn’t that why we are using patterns in the first place?).
Second, because there isn’t an Observable interface, you can’t even create your own
implementation that plays well with Java’s built-in Observer API. Nor do you have
the option of swapping out the java.util implementation for another (say, a new, multi-
threaded implementation).
Observable protects crucial methods

If you look at the Observable API, the setChanged() method is protected. So what? Well,
this means you can’t call setChanged() unless you’ve subclassed Observable. This means
you can’t even create an instance of the Observable class and compose it with your own
objects, you have to subclass. The design violates a second design principle here…favor
composition over inheritance.
What to do?
Observable may serve your needs if you can extend java.util.Observable. On the other
hand, you may need to roll your own implementation as we did at the beginning of the
chapter. In either case, you know the Observer Pattern well and you’re in a good position
to work with any API that makes use of the pattern.
observer and swing
Other places you’ll find the Obser ver Pattern

in the JDK
The java.util implementation of Observer/Observable is not the only place you’ll
find the Observer Pattern in the JDK; both JavaBeans and Swing also provide their
If you’re curious aberout
er Pa tt n in
the Observ
own implementations of the pattern. At this point you understand enough about
observer to explore these APIs on your own; however, let’s do a quick, simple Swing ch ec k ou t the
JavaBeans ener
PropertyChangeList
example just for the fun of it.
A little background... interface.
Let’s take a look at a simple part of the Swing API, the JButton. If you look under
the hood at JButton’s superclass, AbstractButton, you’ll see that it has a lot of add/
remove listener methods. These methods allow you to add and remove observers,
or as they are called in Swing, listeners, to listen for various types of events that
occur on the Swing component. For instance, an ActionListener lets you “listen in”
on any types of actions that might occur on a button, like a button press. You’ll find
various types of listeners all over the Swing API.
A little life-changing application

Okay, our application is pretty simple. You’ve got a button that says “Should I do
it?” and when you click on that button the listeners (observers) get to answer the
question in any way they want. We’re implementing two such listeners, called the
AngelListener and the DevilListener. Here’s how the application behaves:
rface.
Here’s our fancy inte
And here’s the outp ut when

on.
we click on the butt
File Edit Window Help HeMadeMeDoIt
%java SwingObserverExample
Devil answer Come on, do it!
Don’t do it, you might regret it!
Angel answer %
And the code...

This life-changing application requires very little code. All we need to do is
create a JButton object, add it to a JFrame and set up our listeners. We’re going
to use inner classes for the listeners, which is a common technique in Swing
programming. If you aren’t up on inner classes or Swing you might want to
review the “Getting GUI” chapter of Head First Java.
ication that
Simple Swing apfplrame and
public class SwingObserverExample { just creates a on in it.
JFrame frame; throws a butt
public static void main(String[] args) {
SwingObserverExample example = new SwingObserverExample();
example.go();
}
public void go() {

frame = new JFrame(); Makes the devil and
JButton button = new JButton(“Should I do it?”); angel objects listeners
button.addActionListener(new AngelListener()); (observers) of the button.
button.addActionListener(new DevilListener());
frame.getContentPane().add(BorderLayout.CENTER, button);
// Set frame properties here
}
class AngelListener implements ActionListener {

public void actionPerformed(ActionEvent event) {
System.out.println(“Don’t do it, you might regret it!”);
}
Here are t
the observehre class definitions for
}
class DevilListener implements ActionListener { classes (but s, defined as inner

they don’t h
public void actionPerformed(ActionEvent event) { ave to be).
System.out.println(“Come on, do it!”);
}
}
}
Rather than update(), the
actionPerformed() method
gets called when the state
in the subject (in this case
the button) changes.
your design toolbox
Tools for your Design Toolbox BULLET POINTS

Welcome to the end of Chapter 2.
ß The Observer Pattern defines
You’ve added a few new things to your a one-to-many relationship
OO toolbox... between objects.
ß Subjects, or as we also know
them, Observables, update
OO Basics
Observers using a common
interface.
ß Observers are loosely coupled
Abstraction in that the Observable knows
n
Encapsulatio
s
OO Principle
nothing about them, other
m
Polymorphis
than that they implement the
Observer Interface.
Inheritence
a p s u la t e w hat varies. ß You can push or pull data from
En c
osition over
the Observable when using
F a v o r c o m p the pattern (pull is considered
inheritance.
more “correct”).
not
r o g r a m t o interfaces, est
Here’s your newember, ß Don’t depend on a specific
P ions.
implementat principle. Remd designs are order of notification for your
o r lo
d
osely couple that loosely couplelexible and Observers.
St r iv e f much more fchange.
een objects ß Java has several
designs betw resilient to implementations of the
interact. Observer Pattern, including
the general purpose java.util.
Observable.
OO Patterns
ß Watch out for issues with
s, the java.util.Observable
f a m il y of algorithm many implementation.
define s a -to-
Strategy - eeacrhvoenre, -andemfainkess taheomnetorsitshomthat
encapsulaOtebs s
ß Don’t be afraid to create
bejealgc
tbeegtywleetesn toh sutseatite., all its
e n d. eSntc y
r a your own Observable
interchandgep otnlye forbojemcctliecnhtas ntgheast
a b le
nd updated
implementation if needed.
nednen a
vary indewphe ents are n o t if ie d ß Swing makes heavy use of the
depend lly
automatica
Observer Pattern, as do many
GUI frameworks.
ß You’ll also find the pattern in
A new pattern for communicating state to a many other places, including
set of objects in a loosely coupled manner. We JavaBeans and RMI.
haven’t seen the last of the Observer Pattern
- just wait until we talk about MVC!

Observer Pattern

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Observer Pattern

Uploaded by

Copyright:

Available Formats

2 the Observer Pattern

Don’t miss out when something interesting happens! We’ve got a

Your team has just won the contract to build

The Weather Monitoring application over view

three differen t weather stats

Weather-O-Rama provides What we implement

Our job, if we choose to accept it, is to create an app that

Unpacking the WeatherData class

Remember, this Current Co WeatherData.java

What do we know so far ?

R The measurementsChanged() method is called any

R The system must be expandable—other developers

Taking a first, misguided SWAG at

public class WeatherData {

// instance variable declarations

public void measurementsChanged() {

currentConditionsDisplay.update(temp, humidity, pressure);

What’s wrong with our implementation?

public void measurementsChanged() {

ﬂoat temp = getTemperature();

At least we seem to be using a

Umm, I know I’m new

We’ll take a look at

Meet the Obser ver Pattern

1 A newspaper publisher goes into business and begins

2 You subscribe to a particular publisher, and every time

3 You unsubscribe when you don’t want papers anymore,

4 While the publisher remains in business, people, hotels,

Publishers + Subscribers = Observer Pattern

Let’s take a closer look:

The observers have subscribed to

New data values are

The Duck object is now an 2

Duck is psyched... he’s on the

The Subject acknowledges the ct

The Subject has another 14 14

notiﬁcation, except for the

The Obser ver Pattern defined

The Observer Pattern deﬁnes a one-to-many

Automatic update/notification Observers

The subject and observers define the one-to-many relationship.

The Obser ver Pattern defined:

the register and rete subject

methods, the concfyObservers() Concrete observers can be

The power of Loose Coupling

The Observer Pattern provides an object design where

The only thing the subject knows about an observer is that it

Loosely coupled designs allow us to build ﬂexible OO

Let’s also create an

This display shows the weat her

These three display elements should have a pointer to

Implementing the Weather Station

Both of these methods take an

Implementing the Subject interface in

public class WeatherData implements Subject { WeatherData now implements

public void setMeasurements(float temperature, float humidity, float pressure) {

Now, let’s build those display elements

public void update(float temperature, float humidity, float pressure) {

When update() is called, we

save the temp and humidity

recent temp and humidi

Power up the Weather Station

If you don’t CurrentConditionsDisplay currentDisplay =

File Edit Window Help StormyWeather