Design Patterns - Observer Pattern

Introduction

A design pattern is a specific way of solving a particular problem. They are not simply about reusing code; they are more abstract and generalized than that. They are about using reusing ideas.

The Observer Pattern

Often, you'll have data in your application in your application that changes over time. Say that you have some GUI components that are required to show this data and update it when it changes. How would you handle it? One solution might be to pass the newly updated data to a method of the GUI component so that could redraw the information. A problem with this approach is remembering to do that each time the data is updated. What if it's not clear how often the data will be updated, and whether you want the GUI to update automatically when it does?

The observer pattern solves this problem by using two interfaces, Observer and Observable. As the names suggests, the Observer "watches" the Observable to see whether it changes.

Keeping with the theme of human senses, an Observer is sometimes called a Listener, but for this chapter we stick with the former name.

In its most basic implementation, the Observable can add Observers. Observable then is responsible for notifying them if anything about its state has changed, and the Observer is responsible for reacting to the change. In this example, our data is the Observable and the GUI components are the Observers. If the data changes, those changes will automatically be reflected in any GUI component that is an Observer of the data. Next figure demonstrates the observer pattern

Widgets

Continuing with the previous example, you'll use the observer pattern to handle displaying price information for some of the instruments within graphical elements on a Web page. First, you'll need to define some simple graphical components. These components will be basic HTML table structures whose functionality will be contained within an object. Such components often go under the all-purpose term of widgets.

Designing the Widgets

A graphical widget will have two responsibilities. It will need to draw its own HTML so that it can be seen on a Web page, and it will need to update the data it displays. You may have noticed (from previous figure) that an update method is defined in the Observer interface.

Each widget is an Observer. The item being observed is the data representing the instrument name and price information. The data source is Observable.

All widgets, then, should implement the Observer interface. In addition, each one should descend from an abstract class that defines some shared functionality between widget objects. This is an example of using interfaces and abstract class together. Because the update() method is the same for all widgets, it can be implemented in the abstract class. The class diagram is shown in next figure.

Now all concrete implementations of widgets will descend from the AbstractWidget class. The AbstractWidget class in the turn implements the Observer interface. Notice the update() method in the class diagram for AbstractWidget is not shown in italics. This means that the method is actually implemented at that point. The # symbol indicates that the internalData property is protected. That means subclasses of AbstractWidget have access to it. If it were private, subclasses would not be able to access it.

All text and images above is from the book:"Professional PHP5" ISBN: 0-7645-7282-2 (Lecky-Thompson et al., 2005)