C SC 225 Lecture 6: Observer Pattern

[ previous | schedule | next ]

The Observer pattern

• Use this to allow an object of interest to tell other objects about event occurrences
• This is a Behavioral Pattern
• Contributes to "loose coupling", which is very good. Know what this is?
• Observer pattern is critical aspect of Model-View-Controller pattern
• Model-View-Controller (MVC) is ideal arrangement for event-driven code with GUI
• We will cover MVC in more detail later, but here are some basics:
• model encapsulates the "application logic" or "business logic"
• view is the way(s) of displaying the model
• controller receives user input events (e.g. key and mouse) and triggers actions in the other two
• These three are loosely coupled with each other to permit maximum flexibility, extendibility, and maintainability
• Observer pattern is used in MVC for model and view(s) to communicate
• The view(s) observe the model
• When event occurs in model, it notifies the view(s)
• Yes, this is the pattern followed by Java's action listeners
• GUI component maintains list of "interested" action listeners
• Action listener registers its interest through addActionListener() method
• Multiple such listeners may register with the same component
• When an interesting event, such as button click, occurs, all action listeners are notified
• What method carries out the action listener's response?
• What information is that method given?
• Java.util provides a class and interface to support Observer pattern
• Observable class to represent the subject (object of interest)
• Observer interface to represent the observer!
• Observable is a class rather than an interface, because it provides registration and notification mechanism
• Observer interface has only one method, update() in which the implementer codes the observer's response when notified
• The update() method receives two parameters:
• Reference to the Observable object that triggered the call
• Reference to an optional object containing additional information provided by the Observable
• It is better style for the observer to use the Observable reference to get information from the model ("pull") than it is for the Observable to provide it to the Observer through the second parameter ("push").
• In the "pull" case, the observer can query the observable (model) for state information through accessors
• In the "push" case, the Observable has to anticipate all desires, present and future, of the observer!
• The Head First text bemoans the fact that Observable is a class, not an interface
• The limit is the Observable subclass cannot subclass anything else, due to Java's single inheritance
• But if Observable were an interface, you'd have to either write all the register and notify code yourself or extend an abstract class that implements it. In the latter case you use up your inheritance anyway.
• You can get around the single inheritance problem through composition
• Your class can subclass whoever it wants
• It needs to have an Observable field (instance variable)
• It either provides accessor, which exposes this field, or defines its own Observable methods that delegate to that field (but then it does not get benefit of polymorphism)
• What are the limits to this approach?
• If you are masochistic, you can write your own classes for Observer pattern from scratch