Inheritance & Polymorphism

class Animal {
private:
    int age;
};

class Dog : public Animal {
public:
    void birthday() {
        age++;   // COMPILER ERROR — age is private to Animal, even Dog can't touch it!
    }
};

Even though Dog inherits from Animal, private means genuinely NO outside code can access it — and a derived class counts as outside code for this purpose. This is often more restrictive than you actually want.

class Animal {
protected:
    int age;   // derived classes CAN access this
};

class Dog : public Animal {
public:
    void birthday() {
        age++;   // works fine now — protected allows this
    }
};

Dog rex;
rex.age = 5;   // STILL a compiler error — protected blocks OUTSIDE access, same as private

protected sits between public and private: accessible from the class itself AND any class that inherits from it, but still blocked from genuinely outside code — the exact middle ground inheritance often needs.

class Animal {
protected:
    std::string name;
    int age;
public:
    Animal(std::string n, int a) : name(n), age(a) {}
};

class Dog : public Animal {
public:
    std::string breed;

    Dog(std::string n, int a, std::string b) : Animal(n, a), breed(b) {}
    // Animal(n, a) explicitly calls the base class's constructor
};

Dog's constructor calls Animal(n, a) in ITS OWN initializer list — explicitly delegating the base class's setup to the base class's own constructor, rather than duplicating that logic. This is the standard, correct pattern: let each class handle initializing its own part.

When you create a Dog object, C++ ALWAYS runs the base class's constructor FIRST, then the derived class's constructor body — guaranteeing the Animal portion of the object is fully set up before Dog-specific setup runs, which is exactly the order that makes logical sense (you can't specialize a foundation that doesn't exist yet).

class Animal {
public:
    void makeSound() {
        std::cout << "Some generic animal sound" << std::endl;
    }
};

class Dog : public Animal {
public:
    void makeSound() {   // overrides Animal's version
        std::cout << "Woof!" << std::endl;
    }
};

Dog rex;
rex.makeSound();   // prints "Woof!" — Dog's version is used

Defining a function in Dog with the EXACT same name (and parameters) as one in Animal overrides it — when called on a Dog object, Dog's version runs instead of Animal's.

class Animal {
public:
    virtual void makeSound() {   // virtual!
        std::cout << "Some generic animal sound" << std::endl;
    }
};

class Dog : public Animal {
public:
    void makeSound() override {
        std::cout << "Woof!" << std::endl;
    }
};

Animal* ptr = new Dog();
ptr->makeSound();   // NOW prints "Woof!" — the ACTUAL object's type is used

Marking makeSound() as virtual in the base class tells C++ "figure out which version to call based on the object's REAL type, at runtime — not just the pointer's declared type." This is called polymorphism ("many forms") — the same call, ptr->makeSound(), genuinely behaves differently depending on what kind of object ptr actually points to.

Adding override to a derived class's function tells the compiler "I intend for this to override a virtual base-class function — verify that's actually true." If you make a typo in the function name or parameters, override turns what would otherwise be a silent, confusing bug (accidentally creating a NEW, unrelated function instead of overriding) into a clear compiler error instead.

Imagine an array of Animal* pointers, actually holding a mix of Dog, Cat, and Bird objects. With virtual functions, you can loop through and call makeSound() on every single one, identically — and each object automatically responds with ITS OWN correct behavior, without your loop needing to know or check which specific type each one actually is. This is a genuinely different, more flexible style of code than constantly checking types with if/else chains.

Does it make sense to create a bare Shape object? Not really — a "shape" with no specific type is too vague to have a real, meaningful area(). But Circle and Rectangle, both being SPECIFIC shapes, genuinely do have well-defined areas. C++ lets you formally forbid creating a Shape directly, while still requiring every derived class to provide its own area().

class Shape {
public:
    virtual double area() = 0;   // pure virtual — no implementation at all
};

class Circle : public Shape {
private:
    double radius;
public:
    Circle(double r) : radius(r) {}
    double area() override {
        return 3.14159 * radius * radius;
    }
};

The = 0 makes area() a pure virtual function — Shape declares that every real shape MUST have an area(), without providing any implementation itself. A class containing at least one pure virtual function becomes an abstract class.

Shape s;          // COMPILER ERROR — Shape is abstract
Circle c(5.0);    // fine — Circle provides area(), so it's a complete, real class

The compiler itself enforces this — attempting Shape s; is a genuine error, not just bad practice. This is exactly the "formal" enforcement mentioned at the top of this module, replacing what would otherwise just be a documented convention.

class Swimmer {
public:
    void swim() { std::cout << "Swimming" << std::endl; }
};

class Flyer {
public:
    void fly() { std::cout << "Flying" << std::endl; }
};

class Duck : public Swimmer, public Flyer {
    // Duck gets BOTH swim() and fly()
};

A Duck genuinely IS a swimmer AND a flyer — multiple inheritance lets it gain behavior from both, rather than forcing an awkward single-parent hierarchy.

If BOTH Swimmer and Flyer inherit from a common Animal base, Duck ends up with TWO separate copies of Animal's data — one via each path — creating genuine ambiguity about which copy a reference to an inherited Animal member actually means. This shape, drawn out, literally looks like a diamond, giving the problem its name.

An interface is a contract: "any class that implements me guarantees it provides these specific functions." It defines WHAT a class can do, without saying anything about HOW. In C++, this is simply an abstract class (Module 6) where EVERY function is pure virtual — no shared implementation at all, purely a contract.

class Drawable {
public:
    virtual void draw() = 0;
    virtual ~Drawable() {}   // Module 7's rule — virtual destructor
};

class Circle : public Drawable {
public:
    void draw() override {
        std::cout << "Drawing a circle" << std::endl;
    }
};

Any class implementing Drawable guarantees it has a working draw() — that's the entire contract. Multiple, genuinely unrelated classes (a Circle, a Button, an Icon) can all implement Drawable, letting code that only cares about "can this be drawn?" work with all of them uniformly, via polymorphism (Module 5).

Build an abstract Shape class with pure virtual area() and name() methods, two derived classes (Circle and Rectangle), and a function that computes the total area of a mixed collection of shapes — without ever checking each shape's specific type.

#include <iostream>
#include <vector>

class Shape {
public:
    virtual double area() = 0;
    virtual std::string name() = 0;
    virtual ~Shape() {}
};

class Circle : public Shape {
private:
    double radius;
public:
    Circle(double r) : radius(r) {}
    double area() override { return 3.14159 * radius * radius; }
    std::string name() override { return "Circle"; }
};

class Rectangle : public Shape {
private:
    double width, height;
public:
    Rectangle(double w, double h) : width(w), height(h) {}
    double area() override { return width * height; }
    std::string name() override { return "Rectangle"; }
};

int main() {
    std::vector<Shape*> shapes;
    shapes.push_back(new Circle(5.0));
    shapes.push_back(new Rectangle(4.0, 6.0));

    double totalArea = 0;
    for (Shape* s : shapes) {
        std::cout << s->name() << " area: " << s->area() << std::endl;
        totalArea += s->area();
    }
    std::cout << "Total area: " << totalArea << std::endl;

    for (Shape* s : shapes) {
        delete s;   // virtual destructor ensures correct cleanup for each type
    }
    return 0;
}

(This uses std::vector as a resizable collection — Phase 7 covers it properly. For now, just recognize push_back as "add an item.")

• Shape is genuinely abstract (Module 6) — you can never accidentally create a bare, meaningless Shape.
• The loop calling s->area() works identically for every shape type — real polymorphism (Module 5), with zero type-checking logic anywhere.
• virtual ~Shape() (Module 7) guarantees each derived object's cleanup runs correctly when deleted through the base Shape* pointer.