---
title: Why OOP
collection: YouTube 
author: Hitesh Choudhary
updated: 2026-10-12
source: https://docs.chaicode.com/youtube/why-oop
---

# Why OOP

## Why OOP?

Introduction Chapter
Why OOP?
We need to feel the **pain** OOP was invented to fix.
Before we learn classes and objects, we need to feel the pain OOP was invented to fix.
That pain shows up the moment a program grows.

## Procedural code works, **until it doesn't**

Life Before OOP
Procedural code works, **until it doesn't**
Loose data: Data lives in loose variables; logic lives in separate functions.
No guards: Any function can read or change any data.
No ownership: As the program grows, nobody knows who changed what.
String student1Name = "Aman"; int student1Marks = 82; ... Kabir's marks = -40; nothing stops invalid data.
static void printReport(String name, int marks) and updateMarks(String name, int marks) sit far from the data they touch.
This is the shape of procedural code: data here, logic there, no connection enforced.

## What goes wrong at scale

At Scale
What goes wrong at scale
The same loose structure that works for 3 students **breaks** at 10,000.
10,000 students means 20,000 loose variables or messy parallel arrays.
Invalid data (negative marks) slips in because nothing guards it.
Changing one field means hunting through every function that touches it.
Ten developers working on this code will step on each other.
10,000 students means 20,000 loose variables or messy parallel arrays.
Invalid data (negative marks) slips in because nothing guards it.
Changing one field means hunting through every function that touches it.
Ten developers working on this code will step on each other.

## The problem is not writing code. It's **organising** code as it grows.

Key Idea
The problem is not writing code. It's **organising** code as it grows.
Key idea: the problem is not writing code. It's organising code as it grows.

## Things that have **data** and can do actions

What OOP Actually Is
Things that have **data** and can do actions
OOP organises code the way we already think about the world.
A car has data (colour, speed, fuel) and actions (start, brake, accelerate).
A bank account has data (balance, owner) and actions (deposit, withdraw).
A student has data (name, marks) and actions (submit assignment, view report).
Look around you: a car, a bank account, a student — each bundles data with actions.
OOP says: put the data and the actions together, in one unit.
class Student { String name; int marks; void printReport() {...} } — aman.printReport();

## Class vs **Object**

Two Words For This Series
Class vs **Object**
Class
the blueprint.
Written once.
Object
a real thing built from the blueprint.
Created as many times as you need.
Class: the blueprint. Written once.
Object: a real thing built from the blueprint. Created as many times as you need.

## A class is the **blueprint** of a house; objects are the houses built from it.

Key Idea
A class is the **blueprint** of a house; objects are the houses built from it.
Key idea: a class is the blueprint of a house; objects are the houses built from it.

## Four practical problems, **solved**

Why OOP Matters
Four practical problems, **solved**
Code becomes messy as it grows → Related data and logic live together in one class
Invalid data sneaks in → Objects guard their own data and reject bad values
Same code copied everywhere → Reuse through inheritance and composition
Hard to change one part safely → Change a class's internals without breaking its users
OOP is not about fancy syntax. It solves four very practical problems every real project faces.

## OOP in the **real world**

Why Companies Care
OOP in the **real world**
Teams: one developer owns Payment, another owns Order. Clear boundaries.
Maintenance: most of a product's life is spent changing code, not writing it fresh.
Testing: small objects with clear jobs are easy to test.
Interviews: OOP questions show up in almost every Java interview.
Teams: one developer owns Payment, another owns Order. Clear boundaries.
Maintenance: most of a product's life is spent changing code, not writing it fresh.
Testing: small objects with clear jobs are easy to test.
Interviews: OOP questions show up in almost every Java interview.

## Changing Code Is **Most** Of The Job

Key Idea
Changing Code Is **Most** Of The Job
OOP makes code easier to change, and changing code is most of the job.
Key idea: OOP makes code easier to change, and changing code is most of the job.