Design Patterns -- Obeserver

1. The intent of the Observer pattern is to define a one-to-many dependency such that when one object changes state, all its dependents are notified and updated automatically. see pic:

The Subject here is also called Observable. in SmallTalk, we also call Observer and Subject as View and Model.

The progress of Observer is like below:

" the observer registers with the subject, expressing its interest in observing. When a state change occurs, the subject notifies the observer of the change. When the observer no longer wishes to observe the subject, the observer unregisters from the subject. These steps are known as observer registration, notification, and unregistration, respectively." (from Exploring the Observer Design Pattern  Doug Purdy, Microsoft Corporation
Jeffrey Richter, Wintellect)

Register, "The observer invokes the Register method on the subject, passing itself as an argument. Once the subject receives this reference, it must store it in order to notify the observer when a state change occurs sometime in the future. Rather than storing the observer reference in an instance variable directly, most observer implementations delegate this responsibility to a separate object, typically a container. " see pic:

Notification: "When a state change occurs (AskPriceChanged), the subject retrieves all the observers within the container by invoking the GetObservers method. The subject then enumerates through the retrieved observers, calling the Notify method, which notifies the observer of the state change." see pic:

Unregistration, "This sequence is performed when the observer no longer needs to observe the subject. The observer calls the UnRegister method, passing itself as an argument. The subject then invokes the Remove method on the container, ending the period of observation", see pic:

"The use of a container provides the flexibility to support multiple observers per subject. This permits a subject to notify a potentially infinite number of observers of state changes, rather than just one."

For easy understanding, we can simplely combine the diagram above like below, (not whole)

 

2. Observer pattern supports MVC. MVC supports n-tier computing, which brings many practical advatages to software development and deployment. When the pattern uses MVC, 2 requirements must be met  for design:

2.1 Implementations of Observer(who observes...) must register their interest and must update themselves appropriately, often including repainting themselves(in GUI).

2.2 Subclasses of Observable(who is observed) must remember to notify observers when their value changed.

3. When applying MVC, the flow of events may seem indirect. Component(View, Observable) changes caused an update to the bean(Model, Observer). In turn, a change in the bean notifies the Conmponet(View) and they repaint. So changes from GUI layer to the business layer and back to the GUI layer.

4. One pattern of Observer is make the class we want to observe a subclass of Observable. But sometimes the class is already a subclass of another one. In this case, we can provide our class with an Observable object and have our class forward key method calls to it. The Component class in java.awt uses this approach, although it uses a PropertyChangeSupport object instead of an Observable object. In short, this approach implments Observer through delegation instead of subclassing.

Later today I will write an Observer example here to test the pattern.