Functions are the smallest unit of behavior in C++. Interfaces are the contracts that define how parts of a system communicate. Modular design is the discipline that keeps your codebase clean, scalable, and understandable.

This chapter teaches you how modern C++ uses functions and interfaces to build modular systems — the foundation for everything from small libraries to full engines.

A good function answers three questions:

1. What does it do?
2. What does it need?
3. What does it return?

Modern C++ encourages functions that are:

• Short
• Focused
• Pure when possible
• Explicit in their requirements
• Clear in their ownership semantics

Example of clear intent:

float Length(const Vec3& v);

Example of unclear intent:

float doStuff(Vec3* a, Vec3* b);

The second version hides ownership, purpose, and behavior.

Modern C++ uses function signatures to express ownership:

void Translate(Vec3 delta);

void SetColor(const Color& c);

void Normalize(Vec3& v);

void AttachChild(Node* child);

Vec3 Add(const Vec3& a, const Vec3& b);

Clear ownership leads to clear architecture.

A pure function has no side effects:

float Dot(const Vec3& a, const Vec3& b);

A mutating function changes state:

void Rotate(Transform& t, float angle);

Modern C++ encourages pure functions whenever possible because they:

• Are easier to test
• Are easier to reason about
• Are easier to reuse
• Reduce coupling

Mutating functions are used when behavior is intentional and meaningful.

An interface is a promise:

• What a type can do
• What a module expects
• What a system guarantees

In C++, interfaces are expressed through:

• Function signatures
• Abstract classes
• Concepts (C++20)
• Public APIs
• Header boundaries

Example of a simple interface:

class Drawable {
public:
    virtual void Draw() const = 0;
    virtual ~Drawable() = default;
};

This defines a contract without specifying implementation.

Abstract classes define behavior without data.

class InputDevice
{
public:
    virtual bool IsPressed(int key) const = 0;
    virtual ~InputDevice() = default;
};

Derived classes implement the behavior:

class Keyboard : public InputDevice
{
public:
    bool IsPressed(int key) const override;
};

Modern C++ uses polymorphism sparingly — only when dynamic behavior is required.

Static polymorphism avoids virtual calls:

template<typename T>
void Draw(const T& drawable)
{
    drawable.Draw();
}

This is resolved at compile time and is often faster.

C++20 concepts make constraints explicit:

template<typename T>
concept DrawableConcept = requires(T t)
{
    { t.Draw() } -> std::same_as<void>;
};

Use static polymorphism when:

• You want zero cost abstraction
• You don’t need runtime polymorphism
• You want compile time guarantees

A good interface:

• Is minimal
• Is stable
• Has clear ownership rules
• Avoids exposing internal details
• Avoids unnecessary getters/setters
• Avoids forcing inheritance when composition is better

Example of a clean interface:

class Timer
{
public:
    float DeltaTime() const;
    void Update();
};

Example of a poor interface:

class Timer
{
public:
    float* GetInternalPointer();
};

The second version leaks internal representation.

Headers define module boundaries.

A good header:

• Contains declarations, not definitions
• Minimizes includes
• Uses forward declarations when possible
• Avoids global variables
• Avoids unnecessary templates
• Represents a clean API surface

Example:

// Transform.h
#pragma once
#include "Vec3.h"

struct Transform
{
    Vec3 position;
    Vec3 rotation;
    Vec3 scale;
};

This header is clean, minimal, and modular.

Modern C++ encourages:

• Header (.h) → declarations
• Source (.cpp) → definitions

This separation:

• Reduces compile times
• Improves modularity
• Makes code easier to navigate
• Makes libraries easier to build

Example:

// Math.h
float Dot(const Vec3& a, const Vec3& b);

// Math.cpp
float Dot(const Vec3& a, const Vec3& b)
{
    return a.x*b.x + a.y*b.y + a.z*b.z;
}

A module should:

• Have a single responsibility
• Expose a minimal API
• Hide implementation details
• Avoid unnecessary dependencies
• Be easy to test
• Be easy to replace

Examples of good modules:

• btm_math
• btm_input
• btm_time
• btm_assets
• btm_render

Each module has a clear purpose and clean boundaries.

In this chapter, you learned:

• How functions express intent
• How ownership is communicated through signatures
• The difference between pure and mutating functions
• How interfaces define contracts
• How to use abstract classes and polymorphism
• How static polymorphism provides zero cost abstractions
• How to design clean interfaces
• How header boundaries create modular systems
• How to separate interface from implementation
• How to design modules that scale

These principles prepare you for the architectural chapters that follow.