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