Object-Oriented Programming

The four principles in depth

Encapsulation

Encapsulation serves two purposes: data hiding (preventing invalid state by controlling how data is modified) and information hiding (reducing coupling between components by hiding implementation details). These are related but distinct. Data hiding prevents bugs; information hiding enables change — if clients only access an object through its public interface, the implementation can be completely rewritten without breaking the clients.

Inheritance and the Liskov Substitution Principle

Inheritance creates an is-a relationship: a SavingsAccount is a BankAccount. The Liskov Substitution Principle (Barbara Liskov, 1987, formalised 1994) states: if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any desirable properties of the program. In practice: a subclass must honour all the contracts of its superclass — it can extend behaviour, but must not violate it.

Violation example: if BankAccount.withdraw() guarantees the balance never goes negative, and OverdraftAccount overrides it to allow negative balances, code that assumes balances are non-negative will break when given an OverdraftAccount. This is a LSP violation.

Polymorphism: subtype vs. parametric

Subtype polymorphism (runtime polymorphism) is the classic OOP kind: a method call on a base class reference dispatches to the correct subclass method at runtime, via a vtable (virtual function table) in C++ or equivalent mechanism. This is what virtual methods in C++ and all method overriding in Java achieve.

Parametric polymorphism (generics) is a different dimension: a single piece of code works for any type. Java generics (List<T>), C++ templates, Rust generics, and TypeScript generics are all parametric polymorphism. Not specific to OOP — functional languages use it extensively.

Interfaces and abstract classes

Abstraction is concretely implemented through interfaces (in Java, Go, TypeScript) and abstract classes. An interface declares what methods a type must have, without specifying how. Any class that implements the interface can be used wherever the interface is expected. Go's interfaces are structural (implicit) — any type with the right methods satisfies the interface automatically, without declaring it.

interface Account {
    void deposit(double amount);
    double withdraw(double amount);
    double getBalance();
}

class SavingsAccount implements Account {
    private double balance;
    public void deposit(double amount) { balance += amount; }
    public double withdraw(double amount) {
        if (amount > balance) throw new IllegalArgumentException();
        balance -= amount; return balance;
    }
    public double getBalance() { return balance; }
}

// This method works with ANY Account — polymorphism
void processAccounts(List<Account> accounts) {
    for (Account account : accounts) {
        account.deposit(100); // correct method called per type
    }
}

Composition over inheritance

Deep inheritance hierarchies are a recognised design problem — they create tight coupling, make code hard to follow, and violate the Liskov principle when inheritance is used for code reuse rather than genuine is-a relationships. The Gang of Four design patterns book (Gamma et al., 1994) explicitly advises: "favour object composition over class inheritance." Composition uses has-a relationships: a Car has an Engine rather than inheriting from Engine. The engine can be swapped; the car delegates engine-related behaviour to its engine object. This produces more flexible, maintainable designs.

Prototype-based OOP

JavaScript does not use classes in the same way Java does. JavaScript's original OOP model is prototype-based: objects inherit directly from other objects via a prototype chain, without a separate class structure. class syntax in JavaScript (introduced in ES6 / ECMAScript 2015) is syntactic sugar over the prototype chain — the underlying mechanism is unchanged. This matters when debugging prototype chain lookups or understanding how this binding works.

The origin of OOP: Simula and Smalltalk

Simula 67 (Dahl & Nygaard, 1967) introduced classes, objects, inheritance, and virtual procedures. It was designed as a simulation language — entities in a simulation (ships, queues, processes) mapped directly to objects in the program. This physical modelling intuition remains the best way to identify good OOP boundaries: if an entity in the problem domain has both state and behaviour, it is a candidate for an object.

Alan Kay's Smalltalk (Xerox PARC, 1972–1980) pursued a different vision: extreme uniformity and message passing. In Smalltalk, everything — including integers and booleans — is an object. Sending a message to an object (5 + 3 sends the + message to the object 5) is the only way to cause any effect. Late binding — method dispatch resolved at runtime, never at compile time — was fundamental. Kay later said the most important idea in Smalltalk was message passing, not the object system itself.

Vtables and dynamic dispatch

In C++, virtual method calls are implemented via a vtable (virtual function table). Each class with virtual methods has a vtable — an array of function pointers, one per virtual method. Each object has a hidden pointer to its class's vtable. A virtual method call dereferences the vtable pointer and calls through the appropriate function pointer — two pointer dereferences and an indirect call, compared to a direct call for non-virtual methods. This is the cost of runtime polymorphism in C++: ~1–3 ns on modern hardware, often negligible, but a concern in inner loops of high-performance code.

Java uses a similar mechanism via the Method Table (mtable) in the JVM. Python's method dispatch goes through the __mro__ (Method Resolution Order) — a linearisation of the class hierarchy computed via the C3 algorithm (Barrett et al., 1996) — which handles multiple inheritance in a consistent, predictable way.