In earlier lessons, we saw how to draw shapes and handle mouse events for individual elements in SDL. While this works for simple examples, managing dozens or hundreds of UI elements directly in our main function quickly becomes unmanageable.

This lesson introduces techniques for structuring larger SDL applications. We'll learn how to create "manager" classes that take responsibility for specific parts of the UI, keeping our main code clean and organized.

We will cover:

Creating a UI manager class.
Using std::vector to manage multiple components dynamically.
Applying inheritance to create specialized components.
Leveraging polymorphism to handle different component types uniformly.
Building hierarchies of managers for complex UIs.

Starting Point

We'll build upon the code from our previous lesson. This starting point includes an SDL application that initializes the library, creates a Window, and manages a single Rectangle object. The Rectangle handles its own rendering and responds to mouse hover and click events.

Manager Classes

In more complex projects, we're likely to find our game managing thousands or maybe millions of objects. We can't just orchestrate all of them from our main function - that would quickly get unmanagable.

To deal with this, we can introduce intermediate, manager classes that take ownership over some area of our program. For example, we might have a UI class, responsible for managing all the buttons and menus in our program.

That class would need to react to events and render the objects it manages, so let's add HandleEvent() and Render() functions:

1// UI.h
2#pragma once
3#include <SDL.h>
4
5class UI {
6public:
7  void Render(SDL_Surface* Surface) const {
8    // ...
9  }
10
11  void HandleEvent(SDL_Event& E) {
12    // ...
13  }
14};

Now, in our main function, managing the entire UI only requires three lines of code. We construct a UI manager, we notify it of events, and we render it:

1#include <SDL.h>
2#include "Window.h"
3#include "Rectangle.h"
4#include "UI.h"
5
6int main(int argc, char** argv) {
7  SDL_Init(SDL_INIT_VIDEO);
8  Window GameWindow;
9  Rectangle Rect{SDL_Rect{50, 50, 50, 50}};
10  UI UIManager;
11
12  SDL_Event E;
13  while (true) {
14    while (SDL_PollEvent(&E)) {
15      Rect.HandleEvent(E);
16      UIManager.HandleEvent(E);
17      if (E.type == SDL_QUIT) {
18        SDL_Quit();
19        return 0;
20      }
21    }
22
23    GameWindow.Render();
24    Rect.Render(GameWindow.GetSurface());
25    UIManager.Render(GameWindow.GetSurface());
26    GameWindow.Update();
27  }
28
29  return 0;
30}

Let's add some objects for our UI to manage. We'll create three rectangles and, every time our UI receives an event or a request to render, it forwards that request to all of its children:

1// UI.h
2#pragma once
3#include <SDL.h>
4#include "Rectangle.h"
5
6class UI {
7public:
8  void Render(SDL_Surface* Surface) const {
9    A.Render(Surface);
10    B.Render(Surface);
11    C.Render(Surface);
12  }
13
14  void HandleEvent(SDL_Event& E) {
15    A.HandleEvent(E);
16    B.HandleEvent(E);
17    C.HandleEvent(E);
18  }
19
20private:
21  Rectangle A{SDL_Rect{50, 50, 50, 50}};
22  Rectangle B{SDL_Rect{150, 50, 50, 50}};
23  Rectangle C{SDL_Rect{250, 50, 50, 50}};
24};

Dynamic Children

A manager class can have a dynamic number of children by storing them in a container such as a std::vector. Below, we update our UI class to manage 60 rectangles.

Our constructor uses some loops to create all of our rectangles, and some arithmetic to position them into a grid layout:

1// UI.h
2#pragma once
3#include <SDL.h>
4#include <vector>
5#include "Rectangle.h"
6
7class UI {
8public:
9  UI() {
10    int RowCount{5}, ColCount{12};{
11    Rectangles.reserve(RowCount * ColCount);{
12    for (int Row{0}; Row < RowCount; ++Row) {
13      for (int Col{0}; Col < ColCount; ++Col) {
14        Rectangles.emplace_back(SDL_Rect{
15          60 * Col, 60 * Row, 50, 50
16        });
17      }
18    }
19  }
20
21  void Render(SDL_Surface* Surface) const {
22    // ...
23  }
24
25  void HandleEvent(SDL_Event& E) {
26    // ...
27  }
28
29private:
30  std::vector<Rectangle> Rectangles;
31};

When a UI receives a Render() or HandleEvent() request, it now iterates over all of the elements in it's array, forwarding the request to each of them:

1// UI.h
2// ...
3
4class UI {
5public:
6  // ...
7
8  void Render(SDL_Surface* Surface) const {
9    for (auto& Rectangle : Rectangles) {
10      Rectangle.Render(Surface);
11    }
12  }
13
14  void HandleEvent(SDL_Event& E) {
15    for (auto& Rectangle : Rectangles) {
16      Rectangle.HandleEvent(E);
17    }
18  }
19  
20  // ...
21};

Screenshot showing the program rendering a grid of red rectangles

Inheritance

Remember, once we have a class set up, we can use inheritance to extend that class, or provide variations. Let's create a GreenRectangle class that inherits from our Rectangle.

We'll just forward the SDL_Rect to the inherited constructor and then, from the constructor body, set our color to green:

1// GreenRectangle.h
2#pragma once
3#include <SDL.h>
4#include "Rectangle.h"
5
6class GreenRectangle : public Rectangle {
7 public:
8  GreenRectangle(const SDL_Rect& Rect)
9  : Rectangle{Rect} {
10    SetColor({0, 255, 0, 255});
11  }
12};

In our UI class, we can switch to using green rectangles by updating the type of our array:

1// UI.h
2#pragma once
3#include <SDL.h>
4#include <vector>
5#include "Rectangle.h"
6#include "GreenRectangle.h"
7
8class UI {
9// ...
10
11private:
12  std::vector<GreenRectangle> Rectangles;
13};

Screenshot showing the program rendering a grid of green rectangles

Polymorphism

When we're using inheritance, our UI class can store objects of varying types within the same collection. They just need to share the same base class, such as Rectangle.

To use polymorphism, our UI needs to store its children as pointers. We'll use std::unique_ptr for this, as it automates the memory management, and the UI should conceptually "own" the objects that it is managing:

1// UI.h
2// ...
3#include <memory> // For std::unique_ptr
4
5class UI {
6public:
7
8  // ...
9
10private:
11  std::vector<std::unique_ptr<
12    Rectangle>> Rectangles;
13};

Memory Ownership and Smart Pointers

Learn how to manage dynamic memory using unique pointers and the concept of memory ownership

View Related Lesson

As our Rectangles array is now storing pointers rather than Rectangle values, we need to update our Render() and HandleEvent() functions to use the -> operator instead of .:

1// UI.h
2// ...
3
4class UI {
5public:
6  // ...
7  void Render(SDL_Surface* Surface) const {
8    for (auto& Rectangle : Rectangles) {
9      Rectangle.Render(Surface);
10      Rectangle->Render(Surface);
11    }
12  }
13
14  void HandleEvent(SDL_Event& E) {
15    for (auto& Rectangle : Rectangles) {
16      Rectangle.HandleEvent(E);
17      Rectangle->HandleEvent(E);
18    }
19  }
20  // ...
21};

Let's update our constructor to create an alternating grid of red and green rectangles using the modulus operator:

1// UI.h
2#pragma once
3#include <SDL.h>
4#include <vector>
5#include <memory>
6#include "Rectangle.h"
7#include "GreenRectangle.h"
8
9class UI {
10public:
11  UI() {
12    int RowCount{5}, ColCount{12};
13    Rectangles.reserve(RowCount * ColCount);
14    for (int Row{0}; Row < RowCount; ++Row) {
15      for (int Col{0}; Col < ColCount; ++Col) {
16        bool useGreen{(Row + Col) % 2 == 0};
17        Rectangles.emplace_back(useGreen
18        ? std::make_unique<GreenRectangle>(SDL_Rect{
19            60 * Col, 60 * Row, 50, 50})
20        : std::make_unique<Rectangle>(SDL_Rect{
21            60 * Col, 60 * Row, 50, 50})
22        );
23      }
24    }
25  }
26
27  // ...
28};

Screenshot showing the program rendering a grid of red and green rectangles

The `virtual` Keyword

In our previous example, our UI constructor is calling the GreenRectangle constructor on every other iteration of the loop. It is this constructor that sets the rectangle's color to green.

However, invocations of other functions, such as Render(), are using the base Rectangle version of that function, even if the Rectangle smart pointer pointer is specifically pointing to a GreenRectangle.

If we want derived classes to have the option to override the behaviour of a function they're inheriting, we should add the virtual keyword to that function. We introduced virtual here:

Virtual Functions and Overrides

This lesson provides an introduction to virtual functions and overrides, focusing on their role in enabling runtime polymorphism

View Related Lesson

Applying it to Rectangle::Render(), for example, would look like this:

1// Rectangle.h
2// ...
3
4class Rectangle {
5 public:
6 // ...
7
8  virtual void Render(
9    SDL_Surface* Surface
10  ) const {
18  }
19  // ...
20};

Any derived class that overrides this function should add the override keyword:

1// GreenRectangle.h
2// ...
3
4class GreenRectangle : public Rectangle {
5 public:
6  // ...
7
8  void Render(
9    SDL_Surface* Surface
10  ) const override {
11    // ...
12  }
13};

When we want to use polymorphism, it is also highly recommended to mark the base classes destructor as virtual:

1// Rectangle.h
2// ...
3
4class Rectangle {
5 public:
6 // ...
7
8  virtual ~Rectangle() = default;
9  // ...
10};

This is because, if a derived type implements a custom destructor, we want to ensure that destructor is used even if the object is deleted through a reference to the base type.

Non-virtual destructors are a common source of memory leaks as, if the GreenRectangle allocates some memory in its constructor and deallocates it in the destructor, we want to make sure that destructor is used:

1// This will call the GreenRectangle constructor...
2Rectangle* Rect{
3  new GreenRectangle{SDL_Rect{1, 2, 3, 4}}
4}
5
6// ...so we want this to call the GreenRectangle destructor,
7// even though Rect is a base Rectangle pointer
8delete Rect;

Hierarchy

Our UI class successfully abstracts complexity away from main. However, in a large application with multiple distinct UI areas (like a header, main content area, and footer), the UI class itself could become overly complex, managing dozens or hundreds of disparate components.

We can address this simply by repeating the pattern again, introducing another layer of manager-style classes. We can repeat this pattern as many times as needed, thereby creating a hierarchy of managers.

For example, instead of the main UI class managing every single rectangle, it can manage a few higher-level manager objects, each responsible for a specific section of the UI. For example, UI could own instances of Header, Footer, and Grid classes.

The Header class would manage components specific to the header, the Footer class would manage its components, and the Grid class would manage the grid of rectangles.

The top-level UI class then simply delegates tasks: UI::Render() calls Render() on Header, Grid, and Footer, and UI::HandleEvent() forwards events similarly:

1// UI.h
2#pragma once
3#include <SDL.h>
4#include "Header.h"
5#include "Footer.h"
6#include "Grid.h"
7
8class UI {
9public:
10  void Render(SDL_Surface* Surface) const {
11    TopMenu.Render(Surface);
12    Rectangles.Render(Surface);
13    BottomMenu.Render(Surface);
14  }
15
16  void HandleEvent(SDL_Event& E) {
17    TopMenu.HandleEvent(E);
18    Rectangles.HandleEvent(E);
19    BottomMenu.HandleEvent(E);
20  }
21
22private:
23  Header TopMenu;
24  Grid Rectangles;
25  Footer BottomMenu;
26};

In this example program, the Header and Footer class both render a simple gray rectangle, whilst the Grid renders a grid of red rectangles:

Screenshot showing a program rendering a header, grid, and footer

For reference, the Header, Grid, and Footer classes used for this example are provided below:

Where Does the Logic Go?

If we think about our application design as layers in a hierarchy: main is the highest level, followed by UI, then section managers like Grid, and finally individual components like Rectangle.

Conceptually, we can think of code that is placed in classes or functions near the top of this hierarchy as being more impactful than code near the bottom. This is because code placed higher up should generally have broader scope and impact.

Good design practice suggests pushing functionality as far down this hierarchy as is reasonable. If a behaviour relates only to how a rectangle draws itself or responds to input, that logic should live within the Rectangle class. It shouldn't clutter the more important Grid or UI classes, and least of all the main() function.

This concept, often related to encapsulation and cohesion, promotes locality. Keeping behaviour close to the relevant data makes classes more independent, easier to test, and simpler to reason about. High-level classes stay focused on coordination, leading to a cleaner overall architecture.

Component Reuse

Beyond managing complexity, building UIs from components enables code reuse.

For example, let's imagine we wanted to add the ability to load and render an image in our Header class. Even if we can add the required logic without making the Header code excessively complex, it's probably a good idea to create a separate Image component anyway.

This is because the ability to render an image is likely to be useful in many parts of our application, not just the Header class. By creating a separate Image component for this purpose, our work can be reused across other parts of our application that require an image.

Diagram showing an Image Component reused multiple times across a complex UI hierarchy

We'll learn how to render images in the next chapter.

Complete Code

We'll reuse the concepts we covered in this lesson later in the course but, for now, we'll go back to a minimalist UI class that just renders two rectangles.

In the next lesson, we'll continue developing on this framework as we learn techniques that allow our components to communicate with their parents, and each other.

Summary

This lesson focused on structuring SDL programs to help manage complexity. We introduced the UI manager class to simplify main, used std::vector for dynamic component lists, created specialized components like GreenRectangle via inheritance, and managed mixed types using polymorphism and std::unique_ptr.

Key Takeaways:

Manager classes improve organization by encapsulating UI sections.
Use std::vector to manage variable numbers of components.
Inheritance allows extending base component functionality.
Polymorphism provides flexibility in handling different component types via base pointers.
Build UI hierarchies to manage complexity by delegating responsibility.
Component reuse and locality are important design goals.

Structuring SDL Programs