• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Observer Pattern
 

Observer Pattern

on

  • 3,132 views

Observer Design Pattern

Observer Design Pattern

- Head First

Statistics

Views

Total Views
3,132
Views on SlideShare
3,119
Embed Views
13

Actions

Likes
0
Downloads
73
Comments
1

2 Embeds 13

http://www.slideshare.net 12
http://us-w1.rockmelt.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • i cannot understand point 2 on slide 14.
    Why cannot you create your own implementation to work with the Observer API.
    In my view, you can create your own custom implementation and call Observer update method when needed? No?
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Observer Pattern Observer Pattern Presentation Transcript

    • The Observer Pattern
    • 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.
    • 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
    • Weather Data Class • getTemprature() • getPressure() • getHumidity() • measurementChanged() Weather Data Class
    • Our Task Implement measurementchanged() function so that it updates the displays accordingly
    • 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);
    • 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.
    • 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.”
    • 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();
    • 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);}
    • 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); }
    • 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.
    • 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.
    • 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.
    • References… • Head First Design Patterns