The document describes the Observer design pattern used in a weather monitoring application. The weather data object acts as the subject and updates three display objects (current conditions, statistics, and forecast displays) as observers when its measurements change. Initially, the displays were updated directly in the measurementChanged() method, violating encapsulation. The Observer pattern was implemented with the weather data as the subject and display classes implementing the observer interface. Now when a measurement changes, the subject notifies all observer displays to update independently according to the new data.

1. The Observer Pattern

2. Weather Monitoring Application
Weather Data Object
Weather Station Guy that tracks the data
Device that receives the coming from weather
weather data station and updates the
display
Display
Shows the current
weather conditions.

3. Job description
Create an application that uses the weather data
Object to update the three displays for weather
conditions.
The three displays are current conditions, weather
stats and forecast

4. Weather Data Class
• getTemprature()
• getPressure()
• getHumidity()
• measurementChanged()
Weather
Data Class

5. Our Task
Implement
measurementchanged()
function so that it
updates the displays
accordingly

6. Simple Solution
measurementChanged() {
• Float temp = getTemperature();
• Float Pr= getPressure();
• Float Hum = getHumidity();
• currentConditionsDisplay.update(temp,Pr,Hum);
• statisticsDisplay.update(temp,Pr,Hum);
• forecastDisplay.update(temp,Pr,Hum);

7. Problems with the previous approach
We are coding to concrete implementation rather then to
an interface.
We have not encapsulated the part that changes from the
part that remains constant. (Display Changes)
We have no way to add or remove the weather displays at
run time.
If we want to add new display we have to alter code.

8. The Observer Pattern
Similar to Newspaper subscription.
Publishers publish and subscribers read.
Once subscribers unsubscribe publishers wont get anything to read.
Once subscribers subscribe again they get to read.
Publishers are Subject and subscribers are Observer.
“The Observer pattern defines a one to many relationship between a set of
objects. When the state of one changes it is notified to all the others.”

9. Design: Class Diagram
<<interface Subject>> <<interface Observer>> <<interface Display>>
Removesubscriber() update() disp()
addSubscriber()
notifyObservers()
CurrentConditionDisp StatisticsDisplay
WeatherData
Update(); Update();
addSubscriber() disp(); disp();
removerSubscriber()
notifyObservers()
measurementChanged() ForecastDisplay
getTemprature()
getHumidity() Update();
getPressure() disp();

10. Implementation (Subject)
public class WeatherData implements Subject{
private ArrayList Observers;
private float temp,press,hum;
public WeatherData()
{ Observers = new ArrayList();}
Publc void removeObserver(Observer o)
{
int index = Observers.indexOf(o);
Observers.remove(i);
}
Public void notifyObservers()
{
for(I =0;i<Observers.length();i++) {
Observer o = (Observer)Observers.get(i);
o.update(temp,hum,press);
}
}
Public void measurementChanged()
{
notifyObservers();
}
public void addObserver(Observer o)
{Observers.add(o);}

11. Implementation (Observer)
public class CurrentConditionsDisplay implements Observer,Display {
private float temp,hum,press;
private Subject weatherData;
public CurrentConditionsDisplay (Subject s){
this.weatherData = s;
weatherData.addObserver(this);
}
Public void update(float temp, float press, float hum)
{
this.temp= temp; this. Press = press;
display();
}
public void display()
{
System.out.println(“ The current conditions of temperature are good : “+temp);
}

12. Java has built in support for Observer
• You don’t have to implement the addObserver,
removeObserver etc since these are already
implemented in Observable class (not an
interface).
• Both are present in the java.util package.
• You can also implement either pull or push style
to your observers.
• For an object to become Observer:
– Implement the Observer Interface and call
addObserver() on any Observable Object.

13. Cont…
• For the Observable to send notifications:
– You must first call the protected setChanged() method
to signify that the state has changed.
– Then call one of the two notifyObservers() methos
• notifyObservers()
• notifyObservers(Object arg)
– The argument passed is the data Obect.
– For an Observer
• Update(Observable o, Object arg)
– Implements the update method. If you want the push model you
can put the data in the dataObject else in case of pull method the
Observer can get the data when ever it wants.

14. Dark Side of Observer Java Built in Pattern
• The Observable is a class not an interface. Any already
defined class which has already extended a class can not
subclass it.
• You cant create your own implementation that plays well
with Java Built in Observer API.
• Observable protects the setChanged() method hence any
class has to subclass It if they want to use Observable. This
hampers the design principle “favor composite over
inheritance”
• Swing uses the Observer Pattern. Since every button has a
number of listeners. Listeners are observers which wait for
any change in the state of the button and respond
accordingly.

15. References…
• Head First Design Patterns