Introduction to OOP

Object-Oriented Programming (OOP) is a way of organizing code around objects — bundles that combine data (attributes) with the behavior (functions) that operates on that data. Instead of writing a long list of loose functions that pass data back and forth, you model the problem as a set of interacting objects, each responsible for its own state.

C++ was, historically, literally built to bring this style of programming to C. Bjarne Stroustrup started the language in 1979 as “C with Classes” — his goal was to keep C's performance and low-level control while adding the class-based organization he had seen in Simula. That origin story explains a lot about C++'s design: it is a systems language first, with OOP layered on top rather than the sole way of writing code (C++ still fully supports plain procedural and, today, functional-style programming).

Why organize code this way?

As programs grow, keeping data and the logic that manipulates it in separate, scattered places becomes error-prone — any function anywhere can reach in and corrupt a struct's fields. OOP addresses this by:

Grouping related data and functions into a single unit (a class).
Controlling which parts of that unit are visible to the outside world.
Letting new types reuse and extend behavior from existing types.
Allowing code to work with many different types through one common interface.

The four pillars of OOP

Almost every OOP concept in C++ falls under one of four ideas. Each gets its own dedicated page later in this section — here is the map:

Pillar	In one sentence
Encapsulation	Bundle data with the methods that operate on it, and hide internal details behind a controlled interface.
Abstraction	Expose only what a user of a type needs to know; hide the complexity of how it works.
Inheritance	Let one class acquire the members and behavior of another, enabling reuse and hierarchy.
Polymorphism	Let code call the "right" behavior for an object without knowing its exact concrete type.

Note

Encapsulation and abstraction are closely related and sometimes blurred together: encapsulation is the mechanism (access control), abstraction is the goal (a simple mental model). Inheritance and polymorphism are closely related too: inheritance is the mechanism, polymorphism is the payoff.

Classes vs. objects

A class is a blueprint — it describes what data a thing has and what it can do, but it isn't a thing itself. An object is a concrete instance built from that blueprint, living in memory with its own actual values.

A first look: class vs. object

CPP

class Dog {
public:
    std::string name;

    void bark() const {
        std::cout << name << " says woof!\n";
    }
};

int main() {
    // "Dog" is the blueprint. "buddy" and "rex" are objects (instances).
    Dog buddy;
    buddy.name = "Buddy";

    Dog rex;
    rex.name = "Rex";

    buddy.bark(); // Buddy says woof!
    rex.bark();   // Rex says woof!
}

Every object created from Dog has the same shape (a name member and a bark() method), but each has its own independent copy of the data. This distinction — one blueprint, many independent instances — is the foundation everything else in this section builds on: classes and objects (next page), constructors that initialize objects, inheritance between classes, and polymorphism across objects of related classes.