OOP Fundamentals

The last module's Dog class used public, meaning any code outside the class can freely read or change name and age directly — exactly what let something like myDog.age = -50; happen without any resistance.

class Dog {
private:
    int age;   // can ONLY be accessed by Dog's own member functions

public:
    std::string name;
};

Dog myDog;
myDog.age = 3;   // COMPILER ERROR — age is private!

Marking age as private means outside code genuinely cannot touch it directly at all — the compiler enforces this, refusing to compile any code that tries. This is a deliberate design choice, not a limitation to work around: it's the foundation of Module 6's encapsulation.

The common convention in real C++ code: keep member variables private by default, and only make things public when there's a genuine reason external code needs direct access — usually functions, not raw data. You'll see exactly why in Module 6.

class Dog {
public:
    std::string name;
    int age;

    Dog(std::string dogName, int dogAge) {   // the constructor
        name = dogName;
        age = dogAge;
    }
};

Dog myDog("Rex", 3);   // name and age set immediately, in one line

A constructor is a special function — sharing the class's exact name, with no return type at all, not even void — that runs automatically the moment an object is created. It's the natural place to guarantee an object starts out in a valid, fully-initialized state.

Dog(std::string dogName, int dogAge) : name(dogName), age(dogAge) {
    // body can be empty — the : list already did the initialization
}

The : name(dogName), age(dogAge) syntax is called a member initializer list — it's the preferred, more efficient modern C++ style for simple field-setting constructors, though both approaches produce a working result.

If you write NO constructor at all, C++ automatically provides an empty one for you (a "default constructor") that does nothing beyond creating the object. But the moment you write ANY constructor yourself, that automatic one disappears — if you still want a no-argument way to create the object, you need to write it explicitly.

class Dog {
public:
    std::string name;

    Dog(std::string dogName) : name(dogName) {
        std::cout << name << " was created." << std::endl;
    }

    ~Dog() {   // the destructor — note the ~
        std::cout << name << " is being destroyed." << std::endl;
    }
};

The destructor — the class name prefixed with ~ — runs automatically right before an object is destroyed: when a stack (local) object goes out of scope, or explicitly via delete for a heap object.

A destructor is exactly the right place to delete any heap memory the object itself allocated with new during its lifetime — guaranteeing that cleanup happens automatically, every single time an object is destroyed, without you needing to remember to call it manually everywhere the object might go out of scope. This is a genuinely powerful pattern (formally called RAII) that Phase 8's smart pointers build on directly.

Dog rex("Rex", 3);
Dog bella("Bella", 2);

rex.bark();    // prints "Rex says woof!"
bella.bark();  // prints "Bella says woof!"

Both calls run the exact same bark() function code — there's only ONE copy of that function in memory, shared by every Dog object. So how does it know to use rex's name in one call and bella's in the other?

Every non-static member function secretly receives an extra, invisible parameter: this — a pointer to the exact object the function was called on. When you write rex.bark(), C++ effectively passes &rex in as this behind the scenes, and name inside the function body actually means this->name — "the name belonging to whichever object I was called on."

void bark() {
    std::cout << this->name << " says woof!" << std::endl;
    // "this->name" and just "name" mean the exact same thing here
}

Most of the time, you never need to type this yourself — C++ assumes it automatically. It becomes genuinely necessary mainly when a parameter name shadows (matches) a member variable's name, and you need to distinguish them: this->age = age; unambiguously means "set the member variable to the parameter's value," resolving what would otherwise be confusing.

class Dog {
private:
    int age;

public:
    int getAge() {
        return age;
    }
};

A getter is a public function whose only job is returning a private member's value — outside code can now READ age through getAge(), even though it can't touch the variable directly.

void setAge(int newAge) {
    if (newAge >= 0 && newAge <= 30) {   // validation!
        age = newAge;
    } else {
        std::cout << "Invalid age ignored." << std::endl;
    }
}

This is the genuine payoff of encapsulation: a setter can validate a new value BEFORE accepting it — rejecting myDog.setAge(-50) outright, something that was completely impossible to prevent back when age was simply public in Module 1.

Encapsulation means hiding an object's internal data and only exposing it through controlled, well-defined functions. The genuine benefit isn't the getter/setter syntax itself — it's that the class can enforce its own rules about what counts as a valid state, and even change HOW data is stored internally later, without breaking any code that uses the class through its public functions.

class Dog {
public:
    std::string name;
    int age;

    Dog(std::string dogName, int dogAge) : name(dogName), age(dogAge) {}

    Dog(std::string dogName) : name(dogName), age(0) {}  // age defaults to 0
};

Dog rex("Rex", 3);   // uses the first constructor
Dog puppy("Puppy");  // uses the second — age becomes 0

Just like Phase 3's overloaded functions, C++ picks the matching constructor based on how many arguments you provide and their types — exactly the same overload-resolution rule you already know.

Dog(std::string dogName, int dogAge = 0) : name(dogName), age(dogAge) {}

Dog rex("Rex", 3);   // age is 3
Dog puppy("Puppy");  // age defaults to 0 — ONE constructor handles both

int dogAge = 0 in the parameter list means "if the caller doesn't provide this argument, use 0 automatically." This achieves the same flexibility as Module 6's two separate constructors, with less duplicated code — a genuinely useful pattern beyond just constructors, for any function.

class Dog {
public:
    std::string name;
    static int totalDogs;   // shared by EVERY Dog object

    Dog(std::string dogName) : name(dogName) {
        totalDogs++;   // every new Dog increments the SAME shared counter
    }
};

int Dog::totalDogs = 0;   // required: define it once, outside the class

A static member variable exists exactly ONCE, shared by the entire class — not duplicated per object the way name is. Every Dog object created increments the SAME totalDogs, giving you an accurate running count across all of them.

Dog rex("Rex");
Dog bella("Bella");
std::cout << Dog::totalDogs;   // prints 2 — accessed via the CLASS, not an object

You access a static member through the class name itself (Dog::totalDogs), not through any particular object — reflecting that it genuinely belongs to the class as a whole, not to any one Dog.

class Point {
public:
    int x, y;

    Point(int xVal, int yVal) : x(xVal), y(yVal) {}

    Point operator+(const Point& other) {
        return Point(x + other.x, y + other.y);
    }
};

Point a(1, 2);
Point b(3, 4);
Point c = a + b;   // c.x is 4, c.y is 6

operator+ is a specially-named member function — defining it teaches C++ exactly what + should DO when both sides are Point objects. Without it, writing a + b on two Point objects would simply be a compiler error, since C++ has no built-in idea what adding two points should mean.

Operator overloading lets objects of your own classes be used with the same natural, familiar syntax as built-in types — a + b reads far more clearly than an equivalent a.add(b) function call, especially in math-heavy code (vectors, matrices, complex numbers) where the pattern matches how you'd write the equivalent math by hand.

Build a BankAccount class with a private balance that can never go negative, a constructor requiring a starting balance, deposit/withdraw methods with real validation, and a static counter tracking how many accounts have been created.

• balance is private (Module 2) — the only way to change it is through validated deposit/withdraw (Module 6's encapsulation).
• The constructor itself validates the starting balance, guaranteeing no BankAccount can ever start negative — Module 3's job of guaranteeing valid initial state.
• totalAccounts is static (Module 8), correctly shared and incremented across every account created.
• withdraw returns a bool specifically so calling code can check whether it actually succeeded — a genuinely useful, realistic pattern.