C++

Composition, Interfaces & Design

Master composition over inheritance, pure abstract interfaces, design principles (ISP, DIP), std::variant as an alternative to inheritance, and type erasure.

Why Composition Over Inheritance?

"Favor composition over inheritance" is one of the most important principles in OOP design. Inheritance creates a tight coupling between base and derived classes — changes to the base ripple through the entire hierarchy. Composition (having a member of another type) is more flexible: you can change the contained type at runtime, combine behaviors freely, and avoid the fragile base class problem.

Inheritance is appropriate when you need polymorphism (treating different types uniformly through a common interface). For code reuse alone, composition is almost always superior.

Composition in Practice

Instead of inheriting behavior, contain it. A Car is not an Engine — it has an Engine. This gives you freedom to swap engines, test components independently, and evolve each class without breaking the other.

composition.cpp
#include <iostream>
#include <string>
#include <memory>

class Engine {
    int horsepower_;
    std::string type_;

public:
    Engine(int hp, const std::string& type)
        : horsepower_{hp}, type_{type} {}

    void start() const {
        std::cout << type_ << " engine (" << horsepower_ << "hp) started\n";
    }

    int horsepower() const { return horsepower_; }
};

class Transmission {
    int gears_;
public:
    explicit Transmission(int gears) : gears_{gears} {}
    void shift(int gear) const {
        if (gear >= 1 && gear <= gears_) {
            std::cout << "Shifted to gear " << gear << '\n';
        }
    }
};

// Car COMPOSES Engine and Transmission (has-a, not is-a)
class Car {
    std::string model_;
    Engine engine_;
    Transmission trans_;

public:
    Car(const std::string& model, Engine engine, Transmission trans)
        : model_{model}
        , engine_{std::move(engine)}
        , trans_{std::move(trans)} {}

    void drive() const {
        std::cout << model_ << ": ";
        engine_.start();
        trans_.shift(1);
    }
};

int main() {
    Engine v8{450, "V8"};
    Transmission auto6{6};
    Car mustang{"Mustang", std::move(v8), std::move(auto6)};
    mustang.drive();
    return 0;
}

Pure Abstract Interfaces

A pure abstract interface is a class with only pure virtual functions and a virtual destructor — no data, no implementation. This defines a contract that derived classes must fulfill. It supports the Dependency Inversion Principle (DIP): depend on abstractions, not concrete classes.

interface.cpp
#include <iostream>
#include <memory>
#include <string>
#include <vector>

// Pure abstract interface — the contract
class IRepository {
public:
    virtual ~IRepository() = default;
    virtual void save(const std::string& key, const std::string& value) = 0;
    virtual std::string load(const std::string& key) const = 0;
    virtual bool exists(const std::string& key) const = 0;
};

// Concrete implementation: in-memory storage
class MemoryRepository : public IRepository {
    std::vector<std::pair<std::string, std::string>> data_;

public:
    void save(const std::string& key, const std::string& value) override {
        for (auto& [k, v] : data_) {
            if (k == key) { v = value; return; }
        }
        data_.emplace_back(key, value);
    }

    std::string load(const std::string& key) const override {
        for (const auto& [k, v] : data_) {
            if (k == key) return v;
        }
        return "";
    }

    bool exists(const std::string& key) const override {
        for (const auto& [k, v] : data_) {
            if (k == key) return true;
        }
        return false;
    }
};

// Service depends on the INTERFACE, not the concrete class (DIP)
class UserService {
    std::unique_ptr<IRepository> repo_;

public:
    explicit UserService(std::unique_ptr<IRepository> repo)
        : repo_{std::move(repo)} {}

    void register_user(const std::string& username) {
        if (repo_->exists(username)) {
            std::cout << username << " already exists\n";
            return;
        }
        repo_->save(username, "active");
        std::cout << username << " registered\n";
    }
};

int main() {
    auto repo = std::make_unique<MemoryRepository>();
    UserService service{std::move(repo)};

    service.register_user("alice");  // alice registered
    service.register_user("bob");    // bob registered
    service.register_user("alice");  // alice already exists
    return 0;
}

std::variant — Inheritance Alternative

std::variant is a type-safe union that can hold one of several types. Combined with std::visit, it provides compile-time polymorphism — an alternative to virtual functions when the set of types is known at compile time. It avoids heap allocation and virtual dispatch overhead.

variant_poly.cpp
#include <iostream>
#include <variant>
#include <vector>
#include <cmath>
#include <numbers>

struct Circle  { double radius; };
struct Square  { double side; };
struct Triangle { double base, height; };

// Type alias for the closed set of shapes
using Shape = std::variant<Circle, Square, Triangle>;

// Visitor: a callable that handles each type
struct AreaVisitor {
    double operator()(const Circle& c) const {
        return std::numbers::pi * c.radius * c.radius;
    }
    double operator()(const Square& s) const {
        return s.side * s.side;
    }
    double operator()(const Triangle& t) const {
        return 0.5 * t.base * t.height;
    }
};

struct NameVisitor {
    std::string operator()(const Circle&) const { return "Circle"; }
    std::string operator()(const Square&) const { return "Square"; }
    std::string operator()(const Triangle&) const { return "Triangle"; }
};

int main() {
    std::vector<Shape> shapes{
        Circle{5.0},
        Square{4.0},
        Triangle{3.0, 6.0}
    };

    for (const auto& shape : shapes) {
        std::string name = std::visit(NameVisitor{}, shape);
        double area = std::visit(AreaVisitor{}, shape);
        std::cout << name << ": area = " << area << '\n';
    }
    return 0;
}

Type Erasure with std::function

Type erasure lets you store any callable — function, lambda, functor — with a compatible signature in a single std::function object. This is a form of runtime polymorphism without explicit inheritance.

type_erasure.cpp
#include <iostream>
#include <functional>
#include <vector>
#include <string>

// std::function erases the concrete callable type
using Callback = std::function<void(const std::string&)>;

class EventEmitter {
    std::vector<Callback> listeners_;

public:
    void on(Callback cb) {
        listeners_.push_back(std::move(cb));
    }

    void emit(const std::string& event) const {
        for (const auto& cb : listeners_) {
            cb(event);
        }
    }
};

// A functor
struct FileLogger {
    void operator()(const std::string& msg) const {
        std::cout << "[File] " << msg << '\n';
    }
};

void console_log(const std::string& msg) {
    std::cout << "[Console] " << msg << '\n';
}

int main() {
    EventEmitter emitter;

    // Register different callable types — all stored as std::function
    emitter.on(console_log);             // function pointer
    emitter.on(FileLogger{});            // functor
    emitter.on([](const std::string& m) { // lambda
        std::cout << "[Lambda] " << m << '\n';
    });

    emitter.emit("user_login");
    return 0;
}
Best Practice

Interface Segregation Principle (ISP): prefer small, focused interfaces over large, monolithic ones. A class should not be forced to implement methods it does not use. Split IAnimal into IFlyable and ISwimmable if not all animals fly and swim.

Dependency Inversion Principle (DIP): high-level modules should depend on abstractions (interfaces), not concrete implementations. Pass IRepository& instead of MySQLDatabase& — this lets you swap implementations for testing (mock repositories) and different environments.

Pitfall

Deep inheritance hierarchies (4+ levels) become fragile and hard to reason about. A change to a base class can have unexpected effects on distant descendants. The fragile base class problem makes maintenance a nightmare. Prefer flat hierarchies (1-2 levels), use interfaces for polymorphism, and compose behaviors with member objects or std::variant. If your hierarchy depth exceeds 3 levels, it is almost certainly a design smell.

Key Takeaways
  • Composition is more flexible than inheritance — use it for code reuse (has-a relationships)
  • Pure abstract interfaces define contracts and enable the Dependency Inversion Principle
  • std::variant with std::visit provides compile-time polymorphism for closed type sets
  • std::function provides type erasure — store any callable with a compatible signature
  • Keep inheritance hierarchies flat (1-2 levels) and prefer interfaces over concrete base classes
  • Apply ISP (small interfaces) and DIP (depend on abstractions) for maintainable, testable designs

Quiz — Test Your Knowledge

(15 XP)

1. When should you prefer composition over inheritance?

2. What advantage does `std::variant` have over a traditional inheritance hierarchy?

3. What does the Dependency Inversion Principle (DIP) state?

Previous
Static Members, Singletons & PIMPL
Next
Pointers: Addresses, Dereferencing & Arithmetic