Programming and object-oriented design

The ideas behind writing programs that are organised, reusable and easy to change. Every language you use at work builds on them.

Classes and objects

Also called OOP, object-oriented programming, instance

What: A class is a blueprint that bundles data (fields) with behaviour (methods). An object is one instance of a class with its own field values.
Why: Modelling a program as objects that match real things, such as Student or Order, keeps related data and logic together and makes large codebases easier to navigate.

Python

class BankAccount:
    def __init__(self, owner: str, balance: int = 0):
        self.owner = owner
        self._balance = balance

    def deposit(self, amount: int) -> None:
        if amount <= 0:
            raise ValueError("amount must be positive")
        self._balance += amount

acct = BankAccount("Ayesha")
acct.deposit(500)

Encapsulation

Also called information hiding, access modifiers

What: Encapsulation hides an object's internal state and exposes only methods that keep it valid, using private fields or naming conventions like a leading underscore.
Why: Other code cannot put the object in a broken state, such as a negative balance, and you can change the internals without breaking callers.

Watch out

Adding a public getter and setter for every field, which exposes the internals anyway.

Inheritance

Also called subclass, extends

What: Inheritance lets a subclass reuse and extend a parent class, forming an "is a" relationship, such as SavingsAccount extending BankAccount.
Why: It shares common behaviour and lets code treat related types through their parent type.

Watch out

Deep inheritance chains used only to reuse code, where a change in a base class breaks subclasses far away.

Polymorphism

Also called method overriding, method overloading, dynamic dispatch

What: Polymorphism means one interface, many implementations: calling shape.area() runs the right method for a circle or a square. Overriding happens at runtime; overloading picks a method by parameters at compile time.
Why: Code can work with new types without changes, such as a payment flow that accepts any class implementing pay().

Abstraction, interfaces and abstract classes

What: Abstraction exposes what something does and hides how. An interface declares methods with no state. An abstract class can hold shared code and fields but cannot be instantiated.
Why: Depending on an interface, such as Storage, lets you swap a real database for a test fake. Use an interface for a capability, an abstract class for shared base behaviour.

Composition over inheritance

Also called has-a relationship

What: Composition builds behaviour by holding other objects ("has a") instead of inheriting from them ("is a"). A Car has an Engine rather than being one.
Why: Composed parts can be swapped and tested separately, and you avoid rigid class hierarchies that are hard to change later.

SOLID principles

Also called SRP, dependency inversion

What: Five design guidelines: single responsibility, open for extension but closed for modification, Liskov substitution, interface segregation and dependency inversion.
Why: They describe code that is easy to test and change, and they give shared vocabulary for code reviews and design discussions.

Watch out

Applying them mechanically to a small script, creating interfaces and layers nobody needs.

Exceptions and error handling

Also called try catch, try except, exception

What: An exception signals that something went wrong, such as a missing file. Code catches the exceptions it can handle and lets the rest propagate, often with finally or with blocks for cleanup.
Why: Programs that handle errors clearly fail with useful messages instead of crashing or silently producing wrong results.

Watch out

Catching every exception and ignoring it, which hides bugs until they surface somewhere far worse.

Go deeper