OOP Concepts

Low-level design is mostly one question asked repeatedly: what is each piece of code allowed to know about the others? Every class you draw is a line between what a caller may depend on and what you reserve the right to change.

Object orientation is one well-worn set of answers to that question. Its four ideas are usually taught as language features — private fields, abstract classes, extends, method overriding. That framing makes them feel like syntax to memorise. They are more useful read as boundary-drawing tools.

Encapsulation: protecting a rule, not hiding a field

An account balance must never go negative. If the field is public, that rule lives nowhere:

account.balance = -500   # no error, no log, no way to find out later

Nothing is broken yet. It breaks three days later in a report, and the code that caused it is long gone from the stack trace. This is the real cost of exposed state: the failure surfaces far from its cause.

Encapsulation means the only way to change the state is through code that enforces the rule:

class Account:
    def __init__(self):
        self._balance = 0          # internal by convention

    def withdraw(self, amount):
        if amount <= 0:
            raise ValueError("amount must be positive")
        if amount > self._balance:
            raise InsufficientFunds(available=self._balance, requested=amount)
        self._balance -= amount

    @property
    def balance(self):
        return self._balance       # readable, not writable

Now the invariant is checked in exactly one place, and every caller in the codebase gets it for free.

Python has no real privacy: a leading underscore is a convention, and the double underscore in __balance only mangles the name to _Account__balance, which any determined caller can still reach. That is fine. Encapsulation is a design boundary the team agrees to respect; the compiler enforcing it, as in Java or C#, is a convenience rather than the point.

Abstraction: naming what something does, not how

Abstraction is deciding what a caller is allowed to depend on, and writing that down as a contract.

from abc import ABC, abstractmethod

class PaymentProcessor(ABC):
    @abstractmethod
    def charge(self, amount_cents: int) -> str: ...   # returns a transaction id

    @abstractmethod
    def refund(self, transaction_id: str) -> None: ...

Checkout code written against PaymentProcessor has no idea whether the money moves through Stripe's REST API or a bank file uploaded overnight. Swapping one for the other touches one line where the object is constructed.

The value is not that the details are secret — you can read them. It is that nothing depends on them, so changing them cannot break anything.

Inheritance: a promise, not a shortcut

Inheritance is taught as code reuse: put shared fields in a parent, save typing in the children. That framing produces the worst class hierarchies in software.

Inheritance is really a substitutability promise. Writing class Truck(Vehicle) claims that anywhere the program expects a Vehicle, a Truck will behave acceptably. This is the Liskov Substitution Principle, and violating it produces bugs that read as impossible:

class Bird:
    def fly(self): ...

class Penguin(Bird):
    def fly(self):
        raise NotImplementedError("penguins cannot fly")

Every function that safely calls bird.fly() is now a crash waiting for the wrong input. The hierarchy models a biological fact rather than a shared behaviour, and the code pays for it.

The other cost is coupling. A subclass depends on its parent's internals, not just its interface, so changing the parent can silently break children you have never read — the fragile base class problem. And inheritance is fixed at compile time: an object cannot change its class at runtime.

Composition avoids both. Instead of being a thing, hold one:

class Truck:
    def __init__(self, engine, cargo_hold):
        self.engine = engine          # has-a, chosen at runtime
        self.cargo_hold = cargo_hold

The rule of thumb — prefer composition to inheritance — is not a ban. Inheritance earns its place when the subtype truly substitutes for the parent and the shared behaviour is stable, which is why framework base classes work well and business-object hierarchies usually do not.

Polymorphism: deleting the conditional

The four ideas build on one another: encapsulation protects a rule, abstraction names it, inheritance promises it, and polymorphism lets callers depend on the promise rather than the type.

classDiagram
    class PaymentMethod {
        <<interface>>
        +charge(amount) Receipt
    }
    class Card {
        +charge(amount) Receipt
    }
    class BankTransfer {
        +charge(amount) Receipt
    }
    class Checkout {
        -method: PaymentMethod
        +complete() Receipt
    }
    PaymentMethod <|.. Card
    PaymentMethod <|.. BankTransfer
    Checkout --> PaymentMethod

Polymorphism is what makes abstraction pay off. One call site, many behaviours, resolved by the object's actual type.

Its most practical use is removing type-checking chains:

# Every new shipping method edits this function
def cost(order, method):
    if method == "standard":
        return order.weight * 5
    elif method == "express":
        return order.weight * 12 + 30
    elif method == "freight":
        return order.pallets * 400

That elif chain will be copied — badly — into tax calculation, delivery estimates and the tracking page. Each new method means finding and editing all of them, and the compiler will not tell you if you miss one.

Give each method a class implementing a common interface, and the chain collapses to a call:

def cost(order, shipper):
    return shipper.cost(order)       # correct implementation chosen by type

Adding freight now means adding a class, not editing existing functions — the open/closed principle in its most concrete form. Notice that the four ideas are not independent: polymorphism needs a shared contract (abstraction), which is usually declared on a base type (inheritance), over state the caller cannot corrupt (encapsulation).

Check your understanding

Common mistakes

Deep hierarchies. Five levels of inheritance means understanding a method requires reading five files. Two or three levels is usually the practical limit.

Inheriting for reuse rather than substitutability. If you would never pass the child where the parent is expected, you wanted a helper class or composition.

Anaemic classes. Fields plus getters and setters, with all the logic in a separate service, is a struct with ceremony. The rules should live with the data they constrain.

Abstracting one implementation. An interface written before a second implementation exists usually fits the first one exactly and has to be redesigned anyway. Wait for the second case.

Modelling nouns instead of behaviour. Real-world taxonomies rarely make good hierarchies — the penguin problem. Group things by what they do in your system.

Practice

Key takeaways

• Every OOP idea is a boundary decision: what may callers depend on, and what stays yours to change.
• Encapsulation protects an invariant, not a field. Expose the operations that keep the guarantee true, not accessors for every attribute.
• Abstraction is a contract. Its value is that nothing depends on the implementation, so the implementation can change safely.
• Inheritance is a substitutability promise. A subclass that cannot stand in for its parent is a bug waiting to be triggered.
• Prefer composition to inheritance — looser coupling, chosen at runtime, and not limited to one parent chain.
• Polymorphism deletes conditional chains, so new cases become new classes rather than edits to old code.
• The four work together: polymorphism needs a contract, over state the caller cannot corrupt.

Further reading

• Barbara Liskov and Jeannette Wing, "A Behavioral Notion of Subtyping" (ACM TOPLAS, 1994) — the formal basis for the square/rectangle problem.
• Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns (Addison-Wesley, 1994) — including "favour composition over inheritance".
• Joshua Bloch, Effective Java, third edition (Addison-Wesley, 2018), items 18–20 — inheritance versus composition, in practice.
• Alan Kay, "The Early History of Smalltalk" (ACM HOPL, 1993) — what object orientation originally meant by messaging.
• Martin Fowler, Refactoring, second edition (Addison-Wesley, 2018) — "Replace Conditional with Polymorphism".