Delegates and the Observer Pattern

The biggest challenge we have when designing our program is managing how different components communicate with each other. If we manage this poorly, the complexity of our project will quickly get out of hand, making it extremely difficult to add new features or even understand what is going on.

However, if we manage this well, our project will stay understandable and easy to work with, even as we add more and more features.

Imagine we have a Player object and a UIElement class. The UIElement needs to be displayed when our Player is defeated. Let’s review some of the ways we can make this happen

Option 1: Coupling

The first option we have is to solve the problem as directly as possible. Our Player class acquires a reference to the UIElement it needs to affect, and calls a public method at the appropriate time:

1class Player {
2public:
3  void TakeDamage(int Damage) {
4    Health -= Damage;
5    if (Health <= 0) {
6      GameOverScreen->Show();
7    }
8  }
9  
10  UIElement* GameOverScreen;
11  int Health;
12}

This is sometimes referred to as tightly coupling our Player class to our UI class. It has some problems - most notably, having user interface logic in our Player class is not expected.

Whilst quirks like this are manageable in small projects, if we continue to scatter UI code around unrelated classes, those classes will become more complex. Additionally, it will become increasingly difficult to understand how our UI works, as it is being manipulated from a wide assortment of arbitrary objects.

These problems compound further when working in a team. It is likely to be different developers or different subteams working on gameplay and UI logic, so our class will become an entanglement of UI and Player functionality that nobody fully understands.

Spaghetti Code

A project that relies too much on this technique is sometimes unaffectionately compared to spaghetti.

Just as it's difficult to trace a single noodle from one end to the other in a bowl of spaghetti, it becomes challenging to follow the flow of program execution when many different parts of the code are directly calling functions in other, unrelated parts.

Eventually, understanding how changes to one part of your program might affect other parts becomes as difficult as trying to pull out a single strand of spaghetti without disturbing any other part of the bowl.

Option 2: Polling

As an alternative, we can invert this connection. Instead of having our Player class implement UI logic, we can keep our UI logic in a UI class and call Player methods to understand the player’s current state:

1class GameOverScreen : public UIElement {
2public:
3  bool ShouldShow() {
4    return GetPlayer().GetHealth() <= 0;
5  }
6}

This might seem similar to our previous example, but it better achieves encapsulation. UI logic (whether the game over screen should show) stays in a UI class, whilst player logic (how much health they have) remains in the Player class.

Whilst this is a better design, it doesn’t solve our original problem of implementing some behavior when the player’s health reaches 0. To do this, we’d need to check the player’s health over and over again to determine when it reaches 0.

This is sometimes referred to as polling. The ticking mechanism we introduced earlier in this chapter gives us a way to implement this. On every iteration of our application loop, we call a Tick() function on all of our game objects. This allows them to check the state of other objects, and update themselves if needed:

1class GameOverScreen : public UIElement {
2public:
3  void Tick() override {
4    if (GetPlayer().GetHealth() <= 0) {
5      Show();
6    }
7  }
8  
9  void Show() {
10    // ...
11  }
12}

However, we should be mindful of performance considerations. The more logic we have happening on each iteration of our application loop, the slower that loop will iterate. If we frequently rely on adding logic to Tick() functions unnecessarily, our program’s performance will degrade over time as we add more features and objects.

Some functionality does require polling to work correctly, but for this example, and most other scenarios, we can find a better way.

Option 3: Event Systems

The SDL event system we've been working with provides another approach to solving our communication problem. Just as SDL allows us to respond to keyboard and mouse events through its event queue, we can also use this same system to facilitate communication between our game objects.

Instead of objects directly calling methods on each other, we can push custom events onto SDL's event queue that other objects can then receive and handle.

Here's how we can modify our Player class to use SDL's event system to notify other objects when an event happens:

1class Player {
2public:
3  void TakeDamage(int Damage) {
4    Health -= Damage;
5    if (Health <= 0) {
6      SDL_PushEvent(PLAYER_DEFEATED);
7    }
8  }
9  
10  int Health;
11}

With this approach, any object that is connected to SDL's event handling system can now respond to our player's defeat events coming through the event loop:

1class GameOverScreen : public GameElement {
2public:
3  void HandleEvent(SDL_Event& E) override {
4    if (E.type == PLAYER_DEFEATED) {
5      Show();
6    }
7  }
8  
9  void Show() {
10    // ...
11  }
12}

This design pattern prevents unnecessary coupling and typically has significantly better performance than constant polling. However, pushing events through an even system still has a performance cost that is typically excessive for simple communication between two objects.

Additionally, this also relies on an event system being available. Whilst SDL helpfully provides such a system, we’ll often be working on projects that don’t have one.

The Observer Pattern

The observer pattern is a software design technique where objects, typically called observers, can sign up to be notified of events happening in some other object, typically called the subject.

An "event" in this context is simply something that can happen within the subject that might be of interest to the outside world.

If our subject is a Player object, for example, external code might be interested in events like the player taking damage, equipping a new weapon, or leveling up.

The subject then provides a mechanism to allow external code - observers - to be notified when that event occurs.

Delegates

A common mechanism for implementing this involves the observer providing the subject with something it can invoke, such as a function pointer. The subject will then store that callable, and invoke it when the event of interest happens. A callback used in this way is sometimes referred to as a delegate.

In the following example, our Player supports a single observer, which it will notify any time it takes damage. It does this by storing a delegate in the form of a std::function<void()>.

It stores this delegate in a variable called DamageCallback, and provides a SetDamageDelegate() function to allow external code to change it. Within the TakeDamage() function, if the Player is currently holding a delegate, it will invoke it, thereby notifying the observer that the event it was interested in has happened:

1// Player.h
2#pragma once
3#include <functional>
4
5class Player {
6 public:
7  using DelegateType = std::function<void()>;
8  void SetOnDamageObserver(DelegateType D) {
9    OnDamageDelegate = D;
10  }
11
12  void TakeDamage(int Damage) {
13    Health -= Damage;
14    if (OnDamageDelegate) OnDamageDelegate();
15  }
16
17 private:
18  int Health = 100;
19  DelegateType OnDamageDelegate;
20};

Now, any object that wants to become an observer of the Player simply needs to provide a delegate. The Player will then invoke that delegate any time it takes damage:

1#include <iostream>
2#include "Player.h"
3
4void LogDamage() {
5  std::cout << "Player has taken damage";
6}
7
8int main() {
9  Player Subject;
10  Subject.SetOnDamageObserver(LogDamage);
11  Subject.TakeDamage(50);
12}

1Player has taken damage

Delegate Arguments

Like any function, delegates can receive arguments, allowing the subject to provide additional information to the observer. In the following example, we update our Player to invoke the delegate with 3 arguments:

• Which specific Player object is invoking the delegate. This can be helpful if an observer is observing multiple Player objects, and needs to know which one took damage.
• How much damage the Player took
• Who damaged the Player

1// Player.h
2#pragma once
3#include <functional>
4#include <iostream>
5
6class Player {
7public:
8  using DelegateType = std::function<void(
9    Player& P, int Damage, Player& Instigator)>;
10
11  Player(const std::string& Name)
12  : Name{Name} {}
13
14  void SetOnDamageDelegate(DelegateType D) {
15    OnDamageDelegate = D;
16  }
17
18  void TakeDamage(int Damage,
19                  Player& Instigator) {
20    if (OnDamageDelegate) {
21      OnDamageDelegate(
22        *this, Damage, Instigator
23      );
24    }
25  }
26
27  void Attack(Player& Target, int Damage) {
28    Target.TakeDamage(Damage, *this);
29  }
30
31  std::string Name;
32
33private:
34  DelegateType OnDamageDelegate;
35};

We now need to update our delegate to accept and make use of those three parameters:

1// main.cpp
2#include <iostream>
3#include "Player.h"
4
5void LogDamage(
6  Player& Subject,
7  int Damage,
8  Player& Instigator
9) {
10  std::cout << Subject.Name << " has taken "
11    << Damage << " damage from "
12    << Instigator.Name << '\n';
13}
14
15int main() {
16  Player PlayerOne{"Player 1"};
17  Player PlayerTwo{"Player 2"};
18
19  PlayerOne.SetOnDamageDelegate(LogDamage);
20  PlayerTwo.SetOnDamageDelegate(LogDamage);
21
22  PlayerOne.Attack(PlayerTwo, 50);
23  PlayerTwo.Attack(PlayerOne, 25);
24}

1Player 2 has taken 50 damage from Player 1
2Player 1 has taken 25 damage from Player 2

Multiple Observers

In previous examples, our Player subject only supports a single observer. Typically, when we have an object that we want to be observable, we’ll want it to support any number of observers.

Rather than having our Player store a single OnDamageDelegate function, let’s update it to store any number of callbacks in a std::vector.

Then, when the key event happens, our Player will iterate over that array and notify all of its observers. A delegate that can notify multiple observers of an event is sometimes referred to as a multicast delegate:

1// Player.h
2#pragma once
3#include <functional>
4#include <iostream>
5#include <vector>
6
7class Player {
8 public:
9  using DelegateType = std::function<void()>;
10  void AddOnDamageDelegate(DelegateType Callback) {
11    MulticastDelegate.push_back(Callback);
12  }
13
14  void TakeDamage(int Damage) {
15    NotifyOnDamage();
16  }
17
18 private:
19  std::vector<DelegateType> MulticastDelegate;
20
21  void NotifyOnDamage() {
22    std::cout << "Took Damage - Notifying " << MulticastDelegate.size()
23              << " Observer(s)\n";
24
25    for (auto& Callback : MulticastDelegate) {
26      Callback();
27    }
28  }
29};

Below, we create a Player subject, and add two observers to be notified when it receives damage:

1// main.cpp
2#include <iostream>
3#include "Player.h"
4
5void Log(const std::string& ObserverName) {
6  std::cout << ObserverName
7    << ": Player has taken damage\n";
8}
9
10int main() {
11  Player Subject;
12
13  // Register two different callbacks
14  Subject.AddOnDamageDelegate(std::bind_front(Log, "Observer 1"));
15  Subject.AddOnDamageDelegate(std::bind_front(Log, "Observer 2"));
16
17  Subject.TakeDamage(50);
18}

1Took Damage - Notifying 2 Observer(s)
2Observer 1: Player has taken damage
3Observer 2: Player has taken damage

Removing Delegates

The final basic capability we typically need is a mechanism for observers to stop being notified of updates.

Earlier in the chapter, we saw how SDL manages a similar requirement. SDL_AddTimer() returns an SDL_TimerID - an integer that allows us to identify the timer we just added. To remove this timer, we pass its integer to SDL_RemoveTimer():

1int TimerID{
2  SDL_AddTimer(Callback, 1000, nullptr)
3};
4
5// Later:
6SDL_RemoveTimer(TimerID);

Let’s create a similar mechanism for our class. Our Player class can keep track of an additional integer, representing the index of our array where the next delegate is going to be added.

Every time an observer is added, we return this index to the caller of AddOnDamageDelegate(). That same integer can later be passed to RemoveOnDamageDelegate() to update that index to be a nullptr:

When iterating over our array to notify all the observers, we additionally check that the callback at that index is not a nullptr before we invoke it:

1// Player.h
2#pragma once
3#include <functional>
4#include <iostream>
5#include <unordered_map>
6
7class Player {
8 public:
9  using DelegateType = std::function<void()>;
10  int AddOnDamageDelegate(DelegateType D) {
11    MulticastDelegate.push_back(D);
12    return NextObserverIndex++;
13  }
14
15  void RemoveOnDamageDelegate(int Index) {
16    std::cout << "Removing Observer at index " << Index << '\n';
17    if (Index >= 0 && Index < MulticastDelegate.size()) {
18      MulticastDelegate[Index] = nullptr;
19    }
20  }
21
22  void TakeDamage(int Damage) {
23    NotifyOnDamage();
24  }
25
26 private:
27  int NextObserverIndex{0};
28  std::vector<DelegateType> MulticastDelegate;
29
30  void NotifyOnDamage() {
31    std::cout << "Took Damage - Notifying " << MulticastDelegate.size()
32              << " Observer(s)\n";
33
34    for (auto& Callback : MulticastDelegate) {
35      if (Callback) Callback();
36    }
37  }
38};

Now, if an observer wants to stop observing an object, it can store the value returned by AddOnDamageDelegate(), and later pass it to RemoveOnDamageDelegate() when it no longer wants to be notified:

1// main.cpp
2#include <iostream>
3#include "Player.h"
4
5void LogDamage() {
6  std::cout << "Player has taken damage";
7}
8
9int main() {
10  Player Subject;
11
12  int ObserverId{Subject.AddOnDamageDelegate(LogDamage)};
13  Subject.TakeDamage(100);
14  Subject.RemoveOnDamageDelegate(ObserverId);
15  Subject.TakeDamage(100);
16}

1Took Damage - Notifying 1 Observer(s)
2Observer: Player has taken damage
3Removing Observer with Key 1
4Took Damage - Notifying 0 Observer(s)

1// Player.h
2#pragma once
3#include <functional>
4#include <iostream>
5#include <unordered_map>
6
7class Player {
8 public:
9  using DelegateType = std::function<void()>;
10  int AddOnDamageDelegate(DelegateType D) {
11    MulticastDelegate[NextObserverKey] = D;
12    return NextObserverKey++;
13  }
14
15  void RemoveOnDamageDelegate(int Key) {
16    MulticastDelegate.erase(Key);
17  }
18
19 private:
20  int NextObserverKey{0};
21  std::unordered_map<int, DelegateType> MulticastDelegate;
22
23  void NotifyOnDamage() {
24    for (auto& [Key, Callback] : MulticastDelegate) {
25      Callback();
26    }
27  }
28};

Memory Management

Any time we have two discrete objects connected to each other, we should be mindful of their lifecycles. What happens if one of the objects is destroyed before the other?

Observer Destroyed before Subject

In most implementations of the observer pattern, the scenario we should be particularly concerned about is the observer being destroyed before the subject it is observing.

Without intervention, this means the subject may attempt to notify an observer that no longer exists, risking memory corruption:

1// main.cpp
2#include "Player.h"
3#include "Subject.h"
4
5int main() {
6  Player Subject;
7  Observer* DamageObserver{
8    new Observer(Subject)};
9  Subject.TakeDamage(100);
10  
11  delete DamageObserver; 
12  
13  // Subject is going to notify 
14  // DamageObserver about this, but
15  // DamageObserver has been deleted
16  Subject.TakeDamage(100); 
17}

To handle this, we should ensure that the observer correctly unregisters itself from its subjects before it is destroyed. The destructor is the natural place for this:

1#pragma once
2#include <iostream>
3#include "Player.h"
4
5class Observer {
6public:
7  Observer(Player& Subject) : Subject{Subject} {
8    Key = Subject.AddOnDamageDelegate(
9      std::bind_front(&Observer::DamageCallback, this));
10  }
11
12  ~Observer() {
13    std::cout << "Observer Destroyed - "
14      "Unregistering from Subject\n";
15    Subject.RemoveOnDamageDelegate(Key);
16  }
17
18private:
19  void DamageCallback() {
20    std::cout << "A Subject Took Damage\n";
21  }
22
23  Player& Subject;
24  int Key;
25};

1// main.cpp
2#include "Player.h"
3#include "Observer.h"
4
5int main() {
6  Player Subject;
7  Observer* DamageObserver{new Observer(Subject)};
8  Subject.TakeDamage(100);
9  delete DamageObserver;
10
11  // This is now safe
12  Subject.TakeDamage(100); 
13}

1Took Damage - Notifying 1 Observer(s)
2A Subject Took Damage
3Observer Destroyed - Unregistering from Subject
4Removing Observer with id 1
5Took Damage - Notifying 0 Observer(s)

Subject Destroyed before Observer

We also need to consider the possibility that the observer can outlive the subject. In most implementations, this is less problematic. It doesn’t result in memory corruption - instead, the observer will simply no longer receive notifications from a subject that doesn’t exist:

1// main.cpp
2#include "Player.h"
3#include "Subject.h"
4
5int main() {
6  Player* Subject{new Player()};
7  Observer DamageObserver{*Subject};
8  Subject->TakeDamage(25);
9  
10  delete Subject;
11  // DamageObserver is no longer
12  // observing anything
13  
14  // ...
15}

However, our observer may still want to be notified that one of its subjects was destroyed. There are many ways we can implement this.

One of the easiest is to simply have subjects notify observers of their destruction in the exact same way they notify them of any other event. Let’s add an additional multicast delegate and associated methods to our Player class to support this:

1#pragma once
2#include <functional>
3#include <iostream>
4#include <unordered_map>
5
6class Player {
7 public:
8  using DelegateType = std::function<void()>;
9  
10  int AddOnDeathDelegate(DelegateType Callback) {
11    OnDeathMulticastDelegate.push_back(Callback);
12    return NextDeathDelegateKey++;
13  }
14
15  void RemoveOnDeathDelegate(int Index) {
16    if (Index >= 0 && Index < OnDeathMulticastDelegate.size()) {
17      OnDeathMulticastDelegate[Index] = nullptr;
18    }
19  }
20
21  ~Player() {
22    NotifyOnDeath();
23  }
24  
25  // ...
26
27private:
28  int NextDeathDelegateKey{0};
29  std::vector<DelegateType> OnDeathMulticastDelegate;
30
31  void NotifyOnDeath() {
32    std::cout << "Destroying Player - Notifying " << OnDeathMulticastDelegate.size()
33              << " Observer(s)\n";
34
35    for (auto& Callback : OnDeathMulticastDelegate) {
36      Callback();
37    }
38  }
39  
40  // ...
41};

Then, we can update our observer to make use of them:

1#pragma once
2#include <iostream>
3#include "Player.h"
4
5class Observer {
6 public:
7  Observer(Player& Subject) : Subject{Subject} {
8    DamageCallbackID = Subject.AddOnDamageDelegate(
9        std::bind_front(&Observer::DamageCallback, this));
10
11    DeathCallbackID = Subject.AddOnDeathDelegate(
12        std::bind_front(&Observer::DeathCallback, this));
13  }
14
15  ~Observer() {
16    if (DamageCallbackID) {
17      Subject.RemoveOnDamageDelegate(DamageCallbackID);
18    }
19    if (DeathCallbackID) {
20      Subject.RemoveOnDeathDelegate(DeathCallbackID);
21    }
22  }
23
24 private:
25   void DeathCallback() {
26     std::cout << "Subject Destroyed - will "
27       "no longer receive events\n";
28     DamageCallbackID = 0;
29     DeathCallbackID = 0;
30  }
31  
32  int DamageCallbackID;
33  int DeathCallbackID;
34  
35  // ...
36};

Our Observer is now notified when its subject is destroyed, and can react if needed:

1// main.cpp
2#include "Player.h"
3#include "Subject.h"
4
5int main() {
6  Player* Subject{new Player()};
7  Observer PlayerObserver{*Subject};
8  Subject->TakeDamage(25);
9  delete Subject;
10}

1Took Damage - Notifying 1 Observer(s)
2Subject took damage
3Destroying Player - Notifying 1 Observer(s)
4Subject Died - will no longer receive events
5Observer Destroyed - Unregistering from Subject

Advanced: Generic Observers and Subjects

As with any programming task, there are multiple ways we can implement the observer pattern. The approach using delegates is popular in performance-critical contexts, as function pointers are simple constructs with minimal overhead.

To reinforce our learning, let's explore an alternative implementation of the observer pattern that uses inheritance instead of delegates. We'll create generic base classes that any class can inherit to quickly become an observer or subject.

Note that this section uses more advanced C++ features than we've covered so far, including templates and multiple inheritance. If you're not comfortable with these concepts yet, feel free to skip ahead - understanding this section isn't required for the rest of the course.

Creating the Observer Template

In this example, let’s imagine our events are represented by objects, in much the same way SDL’s event loop is implemented. A Player class, for example, could notify observers when they take damage, die, or level up.

They’ll do this by sending PlayerEvent objects to their observers, which identify the specific type of event that happened. These objects can also include arbitrary data or methods if needed:

1// Player.h
2#pragma once
3
4enum class PlayerEventType {
5  HealthChanged, Died, LevelUp
6};
7
8struct PlayerEvent {
9  PlayerEventType Type;
10  int Value;
11};

We’ll provide a class that observers can inherit from to receive such events. Player subjects will call an OnNotify() function on their observers, passing them a PlayerEvent object:

1// Observer.h
2#pragma once
3
4class Observer {
5 public:
6  virtual void OnNotify(const PlayerEvent& E) {}
7};

We’d like observers to support multiple subject types, not just Player objects. So, let’s replace PlayerEvent in this example with a template parameter:

1// Observer.h
2#pragma once
3
4template <typename EventType>
5class Observer {
6 public:
7  virtual void OnNotify(const EventType& E) {}
8};

Now, for a class to become an observer of PlayerEvent objects, it just needs to inherit from Observer<PlayerEvent> and override the virtual OnNotify() function:

1// UIManager.h
2#pragma once
3#include <iostream>
4#include "Observer.h"
5
6class UIManager : public Observer<PlayerEvent> {
7 public:
8  void OnNotify(const PlayerEvent& E) override {
9    if (E.Type == PlayerEventType::HealthChanged) {
10      std::cout << "Player Health changed to " << E.Value << '\n';
11    } else if (E.Type == PlayerEventType::LevelUp) {
12      std::cout << "Player leveled up to Level " << E.Value << '\n';
13    } else if (E.Type == PlayerEventType::Died) {
14      DisplayGameOverScreen();
15    }
16  }
17
18 private:
19  static void DisplayGameOverScreen() {
20    std::cout << "==========================\n";
21    std::cout << "        GAME OVER         \n";
22    std::cout << "==========================\n";
23  }
24};

Creating the Subject Template

Let’s also provide a Subject class template to allow any class to quickly inherit the capability to support observers. This class will have the same capabilities we introduced previously, with methods to add, remove, and notify observers.

Again, we don’t want this to be restricted to just supporting Observer<PlayerEvent> objects, so we instead use the Observer<EventType> type, where EventType is a template parameter:

1// Subject.h
2#pragma once
3#include <vector>
4
5template <typename EventType>
6class Subject {
7 public:
8  int AddObserver(Observer<EventType>* observer) {
9    Observers.push_back(observer);
10    return NextObserverKey++;
11  }
12
13  void RemoveObserver(int id) {
14    if (id >= 0 && id < Observers.size()) {
15      Observers[id] = nullptr;
16    }
17  }
18
19 protected:
20  void NotifyObservers(const EventType& event) {
21    for (auto& Obs : Observers) {
22      if (Obs) Obs->OnNotify(event);
23    }
24  }
25
26 private:
27  std::vector<Observer<EventType>*> Observers;
28  int NextObserverKey{0};
29};

Now, for a class to gain the capability to send observers PlayerEvent notifications, it simply needs to inherit from Subject<PlayerEvent>:

1// Player.h
2#pragma once
3#include "Subject.h"
4
5enum class PlayerEventType { HealthChanged, Died, LevelUp };
6
7struct PlayerEvent {
8  PlayerEventType Type;
9  int Value;
10};
11
12class Player : public Subject<PlayerEvent> {
13  // ...
14};

Within our class code, we then call the inherited NotifyObservers(PlayerEvent&) method any time we want to send an event:

1// Player.h
2#pragma once
3#include "Subject.h"
4
5enum class PlayerEventType { HealthChanged, Died, LevelUp };
6
7struct PlayerEvent {
8  PlayerEventType Type;
9  int Value;
10};
11
12class Player : public Subject<PlayerEvent> {
13 public:
14  void TakeDamage(int damage) {
15    Health -= damage;
16    NotifyObservers({PlayerEventType::HealthChanged, Health});
17    if (Health <= 0) {
18      NotifyObservers({PlayerEventType::Died, 0});
19    }
20  }
21
22  void GainExperience(int exp) {
23    Experience += exp;
24    if (Experience >= 100) {
25      Level++;
26      Experience -= 100;
27      NotifyObservers({PlayerEventType::LevelUp, Level});
28    }
29  }
30
31 private:
32  int Health{100};
33  int Level{1};
34  int Experience{0};
35};

Over in our main function, let’s hook everything up and confirm it’s working:

1// main.cpp
2#include "UIManager.h"
3#include "Player.h"
4
5int main() {
6  Player PlayerOne;
7  UIManager UI;
8
9  int ObserverID{PlayerOne.AddObserver(&UI)};
10
11  // Simulate some game actions
12  PlayerOne.TakeDamage(30);
13  PlayerOne.GainExperience(150);
14  PlayerOne.TakeDamage(100);
15
16  // Remove the observer using the key
17  PlayerOne.RemoveObserver(ObserverID);
18
19  // UI is no longer observing
20  PlayerOne.GainExperience(100);
21}

1Player Health changed to 70
2Player leveled up to Level 2
3Player Health changed to -30
4==========================
5        GAME OVER
6==========================

Multiple Inheritance

Let’s introduce another type of observable subject to our program using this architecture. We’ll create an example NetworkManager class, which can send NetworkEvent objects to its observers.

Now that we have the Subject class template, this becomes much easier - we simply inherit from Subject<NetworkEvent> and call NotifyObservers(&NetworkEvent) as needed:

1// Network.h
2#pragma once
3#include <iostream>
4#include "Subject.h"
5
6enum class NetworkEventType {
7  Connected,
8  Disconnected
9};
10
11struct NetworkEvent {
12  NetworkEventType Type;
13};
14
15class NetworkManager : public Subject<NetworkEvent> {
16 public:
17  void Disconnect() {
18    std::cout << "Network Disconnected\n";
19    NotifyObservers({
20      NetworkEventType::Disconnected
21    });
22  }
23};

Our UIManager class will want to observe both the player and the network manager. Fortunately, C++ supports multiple inheritance. Our UIManager can inherit from both Observer<PlayerEvent> and Observer<NetworkEvent>. The syntax looks like this:

1class UIManager :
2  public Observer<PlayerEvent>,
3  public Observer<NetworkEvent> {
4
5};

Then, we can override the virtual OnNotify() method of both base types. These functions have different parameter lists - one receives PlayerEvent& arguments and the other receives NetworkEvent& arguments - so the compiler understands what we’re overriding:

1// Network.h
2#pragma once
3#include "GameObject.h"
4#include "IObserver.h"
5#include "Player.h"
6#include "Network.h"
7
8class UIManager :
9  public Observer<PlayerEvent>,
10  public Observer<NetworkEvent> {
11public:
12  void OnNotify(const NetworkEvent& E) override {
13    if (E.Type == NetworkEventType::Disconnected) {
14      std::cout << "You are offline\n";
15    }
16  }
17  
18  void OnNotify(const PlayerEvent& E) override {
19    if (E.Type == PlayerEventType::HealthChanged) {
20      std::cout << "Player health changed to "
21        << E.Value << '\n';
22    } else if (E.Type == PlayerEventType::LevelUp) {
23      std::cout << "Player leveled up to level "
24        << E.Value << '\n';
25    } else if (E.Type == PlayerEventType::Died) {
26      DisplayGameOverScreen();
27    }
28  }
29
30 private:
31  void DisplayGameOverScreen() {
32    std::cout << "==========================\n";
33    std::cout << "        GAME OVER         \n";
34    std::cout << "==========================\n";
35  }
36};

Our UIManager objects can now observe both Player and NetworkManager subjects:

1#include "Player.h"
2#include "Network.h"
3
4int main() {
5  Player PlayerOne;
6  UIManager UI;
7  NetworkManager Network;
8
9  int UIObserverKey{PlayerOne.AddObserver(&UI)};
10  int NetObserverKey{Network.AddObserver(&UI)};
11
12  PlayerOne.TakeDamage(30);
13  Network.Disconnect();
14}

1Player health changed to 70
2Network Disconnected
3You are offline

Interfaces

Multiple inheritance is an important capability, but it’s something we should be careful with. If we don’t approach it sensibly, our inheritance hierarchies can become incredibly complex and difficult to reason about.

To help contain this complexity, it can be helpful to self-impose some restrictions on how we use multiple inheritance. One such design pattern is to conceptually imagine our classes having (at most) one "real" base class, but as many "interfaces" as needed.

Whilst an interface is technically a base class in C++, we can imagine it having a more restrictive purpose. We inherit from an interface only to ensure compatibility with some other system that our class wants to use.

For example, for a Goblin object to be compatible with a GameManager system that controls things like ticking, the Goblin class perhaps needs to inherit from an interface called GameObject. That interface includes the virtual Tick(float DeltaTime) function that the GameManager system will be invoking, and that the Goblin can override:

1#include "Monster.h"
2
3class GameObject {
4public:
5  virtual void Tick(float DeltaTime T) {}
6};
7
8class GameManager {
9public:
10  void Tick(float DeltaTime T) {
11    for (auto& Object : GameObjects) {
12      Object->Tick(T);
13    }
14  }
15  
16private:
17  std::vector<IGameObject*> GameObjects;
18};
19
20// Goblins are Monsters that can Tick
21class Goblin :
22  public Monster, // Base Class 
23  public GameObject // Interface 
24{
25public:
26  void Tick(float DeltaTimeT) override {
27    // ...
28  }
29};

To observe a Subject<Player> object, a class must inherit from Observer<Player>, which provides the OnNotify(const PlayerEvent&) function that the Subject<Player> object will be invoking.

1#include "GameManager.h"
2#include "IObserver.h"
3#include "Player.h"
4#include "Network.h"
5
6// UIManagers are GameManagers that can observe
7// Players and Networks
8class UIManager :
9  public GameManager, // Base Class 
10  public Observer<Player>, // Interface 
11  public Observer<Network> // Interface   
12{
13public:
14  UIManager() {
15    GetPlayer().AddObserver(this);
16    GetNetwork().AddObserver(this);
17  }
18  
19  void OnNotify(const PlayerEvent& E) override {
20    // ...
21  }
22  
23  void OnNotify(const NetworkEvent& E) override {
24    // ...
25  }
26};

This conceptual separation between a base class and an interface is so common that many object-oriented programming languages include it within the syntax itself.

For example, Java identifies a base class using the extends keyword, whilst interfaces use implements:

1public class UIManager
2extends Manager
3implements Observer<Player>, Observer<Network> {
4  // ...
5}

C++ has no such distinction within the language. Instead, we typically distinguish interfaces by adopting a naming convention. The most common convention is that classes intended to be an interface will start with I:

1class UIManager :
2  public Manager, // Base Class
3  public IObserver<Player>, // Interface 
4  public IObserver<Network> { // Interface 
5  // ...
6};

We cover multiple inheritance and the related concept of pure virtual functions in much more detail in our advanced course:

Multiple Inheritance and Virtual Base Classes

A guide to multiple inheritance in C++, including its common problems and how to solve them

Pure Virtual Functions

Learn how to create interfaces and abstract classes using pure virtual functions

Summary

In this lesson, we've explored different approaches to managing communication between components in our programs, with a particular focus on the Observer pattern as a flexible and maintainable solution.

By implementing observers and subjects properly, we can create loosely coupled systems that are easier to understand, modify, and maintain over time. Key takeaways:

• Tight coupling between unrelated components (like UI and gameplay) makes code harder to understand and maintain
• Polling for changes can work but often leads to performance issues and isn't suitable for event-based behavior
• The Observer pattern allows objects to subscribe to events they're interested in without creating tight coupling
• Delegates provide a flexible way to implement the Observer pattern, allowing objects to register callbacks
• Multiple observers can subscribe to the same subject using multicast delegates
• Proper memory management is crucial when implementing the Observer pattern. Be mindful of lifecycles - ensure observers unregister themselves when being destroyed
• Use unique identifiers when managing multiple observers to safely remove them later

Next Lesson

Handling Keyboard Input

Learn how to detect and respond to keyboard input events in your SDL-based applications. This lesson covers key events, key codes, and modifier keys.

ContinueView Course