Object-Oriented Programming: Classes, Inheritance Guide.

Object-Oriented Programming (OOP) is a way of writing programs by modelling software as interacting objects — each object bundles data (attributes) and the actions on that data (methods), following the blueprint of its class. A class is the design (like an architect's plan for "Car"); objects are the things built from it (your red car, my blue car).

OOP matters because it mirrors how we think — things with properties that do stuff — and tames large programs. Instead of one giant procedure juggling globals, you get self-contained objects with clear responsibilities, which is why banking software, games and mobile apps are built this way.

Key Concepts

• Class vs object: class = blueprint (defines attributes and methods); object = instance created from it (holds actual values).
• Encapsulation: bundling data with its methods and hiding internals (private attributes, exposed through methods) — outsiders use the controls, not the wiring.
• Inheritance: a child class reuses and extends a parent (class Dog(Animal)) — an "is-a" relationship; types include single, multilevel, hierarchical and multiple inheritance.
• Polymorphism: "many forms" — the same method name behaves differently per class (a Dog's speak() barks, a Cat's meows); overriding is runtime polymorphism, overloading is compile-time.
• Abstraction: exposing what an object does while hiding how — you press "start" without knowing the starter motor's wiring.
• Constructor (__init__ in Python): the special method that initialises a new object; self refers to the object itself.

How It Works

How inheritance + overriding resolve a method call:

1. class Animal defines speak() returning "some sound"; class Dog(Animal) overrides speak() returning "Woof".
2. d = Dog() creates an object whose class is Dog.
3. d.speak() — Python looks for speak in Dog first, finds the override, and runs it: "Woof".
4. Had Dog not defined speak, the lookup would fall through to Animal's version — the child inherits whatever it does not redefine.

Worked Example

How many objects exist? Trace the class variable:

class Counter:<br>&nbsp;&nbsp;&nbsp;&nbsp;count = 0<br>&nbsp;&nbsp;&nbsp;&nbsp;def __init__(self):<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Counter.count += 1<br><br>c1 = Counter()<br>c2 = Counter()<br>c3 = Counter()

1. count = 0 is shared by the class, not copied per object.
2. c1 = Counter() runs __init__ → count = 1.
3. c2 = Counter() → count = 2; c3 = Counter() → count = 3.

Counter.count is 3 — one shared variable tracked all three births. (Instance attributes via self would instead be private to each object.)

Common Misconceptions

• "OOP means everything must be a class." No — forcing tiny scripts into class hierarchies adds noise; OOP pays off as programs grow, not in 20-line scripts.
• "Inheritance is the main point of OOP." Encapsulation and polymorphism matter at least as much; deep inheritance trees often become rigid — prefer composition ("has-a") when reuse is the only goal.
• "Private means truly inaccessible." In Python, the underscore is a convention, not a lock (name mangling aside) — encapsulation there is a social contract enforced by discipline.

Real-World Applications

• GUI frameworks: every button and window is an object inheriting from widget classes (Qt, Tkinter, Android Views).
• Games: players, enemies and projectiles are objects sharing behaviour through inheritance and polymorphism.
• Banking: Account classes encapsulate balances; SavingsAccount and CurrentAccount inherit and specialise.
• Web frameworks: Django models map database tables to classes — each row becomes an object.

OOP builds programs from objects — class blueprints brought to life — organised by four pillars: encapsulation hides the wiring, inheritance reuses the design, polymorphism lets one name wear many behaviours, and abstraction shows only what matters. Think in objects, and large programs stop being intimidating and start being legible.