[펌] Observer pattern (C++)

SENG 609.04 Design Pattern "Observer Design Pattern" April 2, 1998 Stephen Lam

---

1.0    Pattern Overview
1.1    Motive
1.2    Applicability
1.3    Consequences
1.4    Known Uses
1.5    Related Patterns
 
2.0    Class Structure
2.1    Collaborations
2.2    Implementation Issues

3.0    Member Function

3.1    Subject Class
3.2    Observer Class
3.3    ConcreteSubject Class
3.4    ConcreteObserver Class

4.0    Example of Using Observer Pattern - Clock Program

5.0    References

---

1.0    Pattern Overview

The Observer pattern defines an one-to-many dependency between a subject object and any number of observer objects so that when the subject object changes state, all its observer objects are notified and updated automatically.

The Observer pattern is also known as Dependents and Publish-Subscribe.

back to top
 

1.1    Motive
 
The Observer design pattern has two parts and they are subject and observer. The relationship between subject and observer is one-to-many. In order to reuse subject and observer independently, their relationship has to be decoupled.

An example of using the observer pattern is the graphical interface toolkit which separates the presentational aspect with application data. The presentation aspect is the observer part and the application data aspect is the subject part.

In a spreadsheet program, the Observer pattern can be applied as in the following diagram. Each rectangular box in the diagram in an object. SpreadSheetFormula, BarGraph, and PieChart are the observer objects. SpreadsheetData is the subject object. The SpreadsheetData object notifies its observers whenever a data changes that could make it's state inconsistent with the observers.

 

 ##########0* 

Subject	Spreadsheet Data	Send notify signal to observer object whenever data changes
Observer	Spreadsheet Formula Bar Graph Pie Char	Request subject for change information in order to update itself accordingly

 

The relationship between subject and observer can be establish at run time.

back to top
 

1.2    Applicability
 
Use the observer pattern in any of the following situations:
 
• When the abstraction has two aspects with one dependent on the other. Encapsulating these aspects in separate objects will increase the chance to reuse them independently.
  
  
• When the subject object doesn't know exactly how many observer objects it has.
  
  
• When the subject object should be able to notify it's observer objects without knowing who these objects are.
  
  
back to top
 
1.3    Consequences
 
Further benefit and drawback of Observe pattern include:
 
• Abstract coupling between subject and observer, each can be extended and reused individually.
  
  
• Dynamic relationship between subject and observer, such relationship can be established at run time. This gives a lot more programming flexibility.
  
  
• Support for broadcast communication. The notification is broadcast automatically to all interested objects that subscribed to it.
  
  
• Unexpected updates. Observes have no knowledge of each other and blind to the cost of changing in subject. With the dynamic relationship between subject and observers, the update dependency can be hard to track down.
  
  
back to top
 
1.4    Known Uses
 
• Smalltalk Model/View/Controller (MVC). User interface framework while Model is subject and View is observer.
  
  
• Smalltalk ET++, and the THINK class library provide the general Observer pattern.
  
  
• Other user interface toolkits such as InterViews, the Andrew Toolkit, and Unidraw.

back to top
 
1.5    Related Patterns
 
Mediator: Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Singleton: Ensure a class only has one instance, and provide a global point of access to it.

 
back to top
 
2.0    Class Structure
 
The following is class diagram of an observer pattern (Kremer 1998):
 
##########1*

Subject
• Knows it observers
• Has any number of observer
• Provides an interface to attach and detaching observer object at run time

Observer
• Provides an update interface to receive signal from subject

ConcreteSubject
• Store subject state interested by observer
• Send notification to it's observer
  
  
ConcreteObserver
• Maintain reference to a ConcreteSubject object
• Maintain observer state
• Implement update operation
  
  
back to top
 
2.1    Collaborations
 
• ConcreteSubject notifies its observers whenever a change that could make it's state inconsistent with observers.
  
  
• After a ConcreteObserver be notified, it queries the subject state by using the GetState function. ConcreteObserver uses this information to change it's internal state.
  
  
back to top
 
2.2    Implementation Issues
 
Mapping subjects to their observers. A subject can keep track it's list of observers as observer reference or in a hash table.

Observing more than one subject. It might make sense to implement many-to-many relationship between subject and observer. The Update interface in observer has to know which subject is sending the notification. One of the implement is that subject can pass itself as a parameter in the Update operation.

Who triggers the update (Notify operation in Subject).

• State setting operation in subject to trigger Notify.
• Observer to trigger Notify.
  
  
Dangling references to deleted subjects. Deleting a subject or a observer should not produce dangling references.

Making sure subject state is self-consistent before notification. Otherwise, an observer can query subject's intermediate state through GetState operation.

Avoiding observer-specific update protocols: push and pull models.

• Push model: subject sends details change information to observer.
• Poll model: subject sends minimum change information to observer and observer query for the rest of the information.
  
  
Specifying modifications of interest explicitly. One can register observer for only specific events. This can improve update efficiency.

Encapsulating complex update semantics. For any complex set of subject and observer relationships, one can implement Change Manage to handle their Update operation. For example, if multiple subjects have to change state before any of their observers can update. Change Manager can handle change and update sequence for the operation.

back to top
 

3.0    Member Function

The Observer pattern has four major classes. This section describes each class's member functions at the coding level.

See the source files for the Observer pattern

back to top
 

3.1    Subject Class

Subject() is the constructor. It is not used in our implementation and this helps to keep the code generic. However, there are possibilities to use it for some applications.

~Subject() is the distructor. It is not used in our implementation and this helps to keep the code generic. However, there are possibilities to use it for some applications.

void Attach(Observer*) establishes the relationship between Subject and Observer by attaching the input Observer to the _observers list.

void Detach(Observer*) terminates the relationship between Subject and Observer by removing the specified Observer from the _observers list.

vector<Observer*> _observers declares an array of Observer type pointers.

back to top
 

3.2    Observer Class

Observer() is the constructor. It is not used in our implementation and this helps to keep the code generic. However, there are possibilities to use it for some applications.

~Observer() is the distructor. It is not used in our implementation and this helps to keep the code generic. However, there are possibilities to use it for some applications.

virtual void Update(Subject *theChangeSubject) = 0 defines the function Update() that interfaces with the Subject class. This function is called by object of the type Subject.

back to top
 

3.3    ConcreteSubject Class

The ConcreteSubjectClass needs to implement functions for its observer objects to query subject state after sending the notify signal.

It needs function to maintain its internal state. Whenever it has a state change, it has to notify all of its observers.

back to top
 

3.4    ConcreteObserver Class

ConcreteObserver(ConcreteSubject *) establishes the relationship with the input subject by using the Subject class function Attach()

~ConcreteObserver() terminates the relationship with the subject by using the Subject class function Detach()

void Update(Subject *) updates the object's internal state to synchronize with its subject. It uses member functions in the subject object to find out the subject's current state. This Update() function is called by the subject object.

ConcreteSubject *_subject maintains a reference to its subject.

back to top
 

4.0    Example of Using Observer Pattern - The Clock Program
 
The following example based on the idea from Gamma, E., Helm, R., Johnson, R. & Vlissides, J., 1995. It is a clock program that presents time in both analog and digital format.
 

Observer Pattern   Class name	Clock Program   Class Name	C++ file
Subject	Subject	observer.cpp  observer.h
ConcreteSubject	ClockTimer	ClockTimer.cpp  ClockTimer.h
Observer	Observer	observer.cpp  observer.h
ConcreteObserver	AnalogClock  DigitalClock	AnalogClock.cpp  AnalogClock.h  DigitalClock.cpp  DigitalClock.h

Class names of the Clock program and their filenames

Both the Subject class and the Observer class are written in a very generic way and they can be reused in other application without modification.

The ConcreteSubject class and the ConcreteObserver class contain application specific code. However, their class structure can still be reused with modification.

The clock program is written in MS-Visual C++ 4.0. For demo. purpose, both the AnalogClock and the DigitalClock only prints out time in ASCII when they receives the notify signal from the ClockTimer. The following are the C++ sources filenames.
 

AnalogClock.cpp
AnalogClock.h
ClockTimer.cpp
ClockTimer.h
DigitalClock.cpp
DigitalClock.h
main.cpp
observer.cpp
observer.h

See the C++ sources files

back to top
 

5.0    References
 
Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Reading Mass., Addison Wesley.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. & Stal, M. (1996). A System of Patterns: Pattern-Oriented Software Architecture. West Sussex, England, John Wiley & Sons.

back to top

---

April 2, 98
Stephen Lam
lamsh@cpsc.ucalgary.ca

home