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



    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.

      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.

    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 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

안정적인 DNS서비스 DNSEver DNS server, DNS service
Posted by 키르히아이스
,