Observer

Intent

A one-to-many dependency between object so that when one object (subject) changes, all its dependents (observers) are notified and update automatically.

A meta-point is that while we could achieve consistency by making the classes tightly coupled, we don’t want to do that because tight coupling reduces reusability.

Sample Code

An abstract class defines the Observer interface:

class Subject;

class Observer {
 public:
  virtual ~Observer();

  // To support multiple subjects for each observer, we pass
  // `changed_subject`.
  virtual void Update(Subject* changed_subject);

 protected:
  Observer();
};

An abstract class defines the Subject interface:

class Subject {
 public:
  virtual ~Subject();
  virtual void Attach(Observer*);
  virtual void Detach(Observer*);
  virtual void Notify();

 protected:
  Subject();

 private:
  // Notice that we do not make assumptions on the number of observers.
  //
  // We also do not make assumptions on the concrete classes. As long as
  // the class implements the Observer interface, we're good! The
  // coupling is abstract and minimal.
  List<Observer*> observers_;
};

void Subject::Attach(Observer* observer) {
  observers_.Append(observer);
}

void Subject::Detach(Observer* observer) {
  observers_.Remove(observer);
}

void Subject::Notify() {
  // In this design (pull model), we do not tell the observers what
  // exactly changed in `this`. It is up to the concrete observer to
  // query the concrete subject. The concrete observer can also choose
  // to ignore the notification.
  for (Observer* observer : observers_) observer->Update(this);
}

An example concrete Subject, ClockTimer, that stores and maintains the time of day:

class ClockTimer : public Subject {
 public:
  ClockTimer();
  virtual int GetHour();
  virtual int GetMinute();
  virtual int GetSecond();

  // Methods that eventually call `Notify()` should be labelled as such,
  // so that callers can be aware of the cost of a seemingly innocuous
  // operation.
  void Tick();
};

// Called by an internal timer at regular intervals.
void ClockTimer::Tick() {
  // Update internal-time keeping state.
  // ...
  Notify();
}

An example concrete Observer, DigitalClock, that displays the time of day.

class DigitalClock: public Widget, public Observer {
 public:
  DigitalClock(ClockTimer*);
  virtual ~DigitalClock();

  // From Observer
  void Update(Subject*) override;

  // Widget
  void Draw() override;

 private:
  ClockTimer* subject_;
};

DigitalClock::DigitalClock(ClockTimer* subject) {
  subject_ = subject;
  subject_->Attach(this);
}

DigitalClock::~DigitalClock() {
  subject_->Detach(this);
}

void DigitalClock::Update(Subject* changed_subject) {
  if (changed_subject == subject_) Draw();
}

void DigitalClock::Draw() {
  // Get the new values from the subject.
  int hour = subject_->GetHour();
  int minute = subject_->GetMinute();
  int second = subject->GetSecond();

  // Draw the digital clock.
}

Usage:

ClockTimer* timer = new ClockTimer();
DigitalClock digital_clock = new DigitalClock(timer);

Commentary on Design Decisions

Communication Flow

If concrete_observer calls concrete_subject->SetState(new_state), then concrete_observer should hold off making any internal updates until it receives an update notification from concrete_subject. This deferral is important because there may be other objects that call concrete_subject->SetState(new_state).

Who calls Subject::Notify? If state-setting ops on Subject call Notify, we might have several consecutive ops cause several consecutive updates, which may be inefficient. If clients are responsible, then errors are likely since some clients might forget to do it.

Avoiding Dangling References

Deleting a subject should not produce dangling references in its observers. One solution is have the subject notify its observers when as it is deleted, so that observers can reset their reference to it. Deleting the observers is not a solution because the observers might be referenced elsewhere, e.g. listening to other subjects.

Maintaining Consistency of the Subject

We also need to ensure that the subject is self-consistent before notification. For example, this code is buggy:

void MySubject::Operation(int new_value) {
  BaseClassSubject::Operation(new_value);
  // Trigger notification.
  my_internal_value_ += new_value;
  // Update subclass state (too late!)
}

One solution is to send notifications from template methods in the abstract Subject class, e.g.

void Text::Cut(TextRange r) {
  ReplaceRange(r);  // Redefined in subclasses.
  Notify();
}

Specificity/Efficiency of Update Protocols

There’s a tradeoff on the specificity of Update protocols. In the push model, the subject sends detailed information about the change, while in the pull model, the subject sends out the most minimal notification, and the observers must explicitly ask for details. The push model makes observers less re-usable, while the pull method may be inefficient.

Allowing observers to register for specific events of interest can improve update efficiency. An API like this one is a possible solution:

void Subject::Attach(Observer*, Aspect& interest);

void Observer::Update(Subject*, Aspect& interest);

In some cases, the updates may inundate the observer, e.g. the subject’s changing state several times a second. The observer may incorporate a timer to represent the approximate state of the model at a regular interval.

Orchestrating Complex Relationships Between Subjects and Observers

The dependency relationships between subjects and observers may be complex, e.g. an operation that involves changes to several interdependent subjects, and there is a need to ensure that observers are notified only after all subjects have been modified, that a ChangeManager is useful:

void Subject::Notify() {
  change_manager_->Notify();
}

class ChangeManager {
 public:
  Register(Subject*, Observer*);
  Unregister(Subject* Observer*);
  Notify();
}

void ChangeManager::Notify() {
  // A naive implementation that sends notifications to all observers.
  for (Subject* s : subjects_) {
    for (Observer* o : s->observers) {
      o->Update(s);
    }
  }
}

ChangeManager::Notify can be smarter, e.g. maintaining a DAG such that if an Observer* o observes multiple subjects, then o->Update(s) will only be called once to avoid redundant updates.

Combining Subject and Observer Interfaces in the Same Class

Note that some languages, e.g. Smalltalk, lack multiple inheritance (MI). In such cases, it makes sense to combine the Observer and Subject interface in the same class.

References

1. Design Patterns > Behavioral Patterns > 7. Observer. Erich Gamma; Richard Helm; Ralph Johnson; John Vlissides. Oct 21, 1994.
2. Thinking in C++, 2nd Ed, Vol. 2. Chapter 10: Multiple inheritance. Bruce Eckel; Chuck Allison. www.cs.cmu.edu . 1999. Accessed Sep 29, 2021.
3. ruby on rails - Observers vs. Callbacks. stackoverflow.com . 2009. Accessed Sep 29, 2021.
4. base/observer_list_types.h - chromium/src - Git at Google. chromium.googlesource.com . Accessed Sep 29, 2021.
5. base/observer_list.h - chromium/src - Git at Google. chromium.googlesource.com . Accessed Sep 29, 2021.
6. Iterator invalidation rules for C++ containers. stackoverflow.com . Accessed Sep 29, 2021.
7. base/observer_list_threadsafe.h - chromium/src - Git at Google. chromium.googlesource.com . Accessed Sep 29, 2021.
8. base/scoped_observation.h - chromium/src - Git at Google. chromium.googlesource.com . Accessed Sep 29, 2021.
9. base/scoped_multi_source_observation.h - chromium/src - Git at Google. chromium.googlesource.com . Accessed Sep 29, 2021.
10. Observer pattern. en.wikipedia.org . Accessed Sep 29, 2021.