Object-Oriented Programming
with Java
Every concept, every pillar, every diagram you need - what OOP is, why it exists, how Java implements it, and how it's actually used in real systems. Read it here, or grab the full notes below.
What is OOP, and why does it exist?
What is it?
A paradigm that organizes code around objects — self-contained units combining data (fields) and behavior (methods) — instead of a linear list of instructions.
Why use it?
It mirrors how we naturally think about the real world — cars, accounts, employees — so code maps to problem domains instead of fighting them. It also keeps large codebases maintainable.
Why is it needed?
Procedural code with shared global state gets fragile fast. OOP contains change: fixing or extending one class shouldn't force you to touch ten unrelated functions.
Procedural vs Object-Oriented
| Approach | Procedural (C-style) | Object-Oriented (Java) |
| Unit of design | Functions acting on data | Objects bundling data + behavior |
| Data safety | Global/shared data, easily corrupted | Encapsulated, access-controlled |
| Code reuse | Copy-paste or function libraries | Inheritance & composition |
| Scalability | Gets tangled as codebase grows | Modular — classes evolve independently |
| Real-world mapping | Low — thinks in steps | High — thinks in entities & relationships |
| Change impact | Ripples across functions | Contained inside the responsible class |
Classes & Objects
A class is the blueprint. An object is the thing you actually build from it.
public class Car {
private String brand;
private int speed;
// constructor
public Car(String brand) {
this.brand = brand;
this.speed = 0;
}
public void accelerate(int amount) {
speed += amount;
}
public void printStatus() {
System.out.println(brand + " is going " + speed + " km/h");
}
}
// creating objects — each is an independent instance
Car tesla = new Car("Tesla");
Car civic = new Car("Honda");
tesla.accelerate(60);
civic.accelerate(30);
tesla.printStatus(); // Tesla is going 60 km/h
civic.printStatus(); // Honda is going 30 km/hThe Four Pillars of OOP
Every OOP concept in Java branches out from these four ideas.
Bundle data + behavior, hide the internals.
Encapsulation means wrapping fields and the methods that operate on them inside a single class, and restricting direct access to the fields from outside. The class exposes only what's needed through public methods (getters/setters), while the actual data stays private.
Why it matters: Without it, any part of a program could reach in and corrupt an object's state directly. Encapsulation protects invariants — e.g. a bank balance can never be set to a negative number if the setter enforces that rule.
Think of a medicine capsule: the drug (data) is sealed inside, and you interact with it only through the outer shell (methods) — you never touch the raw powder directly.
public class BankAccount {
// fields are private — hidden from outside
private double balance;
public BankAccount(double openingBalance) {
this.balance = openingBalance;
}
// public methods control access to the data
public double getBalance() {
return balance;
}
public void deposit(double amount) {
if (amount > 0) balance += amount;
}
public void withdraw(double amount) {
if (amount > 0 && amount <= balance) {
balance -= amount;
} else {
System.out.println("Invalid withdrawal");
}
}
}
// usage
BankAccount acc = new BankAccount(1000);
acc.deposit(500);
acc.withdraw(200);
System.out.println(acc.getBalance()); // 1300.0
// acc.balance = -50; // ❌ not allowed, balance is privateObject Relationships
How objects connect to each other — from a loose reference to full ownership.
Association
A general "uses-a" link. A Teacher teaches Students — neither owns the other's lifecycle.
class Teacher { Student student; }Aggregation
A "has-a" relationship where the part can exist independently. A Department has Employees, but they still exist if the Department is deleted.
class Department { List<Employee> staff; }Composition
Strong ownership — the part cannot exist without the whole. A House's Rooms disappear if the House is destroyed.
class House { private final Room room = new Room(); }static, final & the Object class
class Counter {
static int count = 0; // shared across all instances
final String id; // set once, never changed
Counter() {
count++;
id = "COUNTER-" + count;
}
}
Counter a = new Counter();
Counter b = new Counter();
System.out.println(Counter.count); // 2 — shared field
System.out.println(a.id); // COUNTER-1
// a.id = "X"; // ❌ compile error — final cannot be reassignedclass Point {
int x, y;
Point(int x, int y) { this.x = x; this.y = y; }
@Override
public String toString() {
return "Point(" + x + ", " + y + ")";
}
@Override
public boolean equals(Object o) {
if (!(o instanceof Point)) return false;
Point p = (Point) o;
return x == p.x && y == p.y;
}
@Override
public int hashCode() {
return Objects.hash(x, y);
}
}
Point p1 = new Point(1, 2);
Point p2 = new Point(1, 2);
System.out.println(p1); // Point(1, 2)
System.out.println(p1.equals(p2)); // trueOOP Cheat Sheet
Every keyword you'll actually type, in one glance.
classBlueprint for creating objects
objectInstance of a class, created with `new`
thisRefers to the current object instance
superRefers to the immediate parent class
extendsClass inheritance (single, in Java)
implementsA class fulfilling an interface contract
abstractClass/method with no full implementation
interfacePure contract of method signatures
privateAccessible only within the same class
protectedAccessible in same package + subclasses
publicAccessible from anywhere
(default)Accessible only within the same package
staticBelongs to the class, not any instance
finalCannot be overridden / reassigned / extended
@OverrideMarks a method as overriding a parent's
instanceofChecks an object's runtime type
OOP Roadmap
Follow this order — each step builds on the last.
Classes & Objects
Fields, methods, `this`, constructors
Encapsulation
Access modifiers, getters/setters
Inheritance
extends, super, method overriding
Polymorphism
Overloading vs overriding, dynamic dispatch
Abstraction
Abstract classes vs interfaces
Object methods
toString(), equals(), hashCode()
Relationships
Association, aggregation, composition
static & final
Class-level members, immutability
SOLID principles
Writing OOP that scales cleanly
Design patterns
Singleton, Factory, Observer, Strategy
Where OOP actually gets used
Enterprise software
Banking, ERP & billing systems model real entities (Account, Invoice, Customer) directly as classes.
Android & desktop apps
UI components (Activity, View, Fragment) are all class hierarchies built on inheritance.
Game development
Player, Enemy, Weapon — polymorphism lets one update loop handle every game object uniformly.
Frameworks & libraries
Spring, Hibernate, and most Java frameworks rely on interfaces + abstraction to stay extensible.
Simulation systems
Traffic, physics, or crowd simulations map naturally onto interacting objects with their own state.
Features, theory & the future of OOP
Why OOP still matters in 2026
Functional programming and multi-paradigm languages have grown fast, but OOP hasn't gone anywhere — it's merged with them. Modern Java (records, sealed classes, pattern matching) keeps the object model but borrows functional ideas like immutability. Most large-scale systems — banking cores, Android, enterprise backends — are still organized around objects because teams of people reason about entities and responsibilities more easily than about pure data transformations.
The real cost of skipping it
Codebases that skip OOP discipline don't fail immediately — they fail slowly. A few global functions mutating shared state work fine for a weekend project, then become unmaintainable once five people touch the same file. Encapsulation and clear class boundaries are what let a team split a large system into pieces that can be worked on, tested, and reasoned about independently.
Where it's heading
The trend isn't 'OOP vs functional' — it's OOP absorbing functional safety nets. Java's records give you value-object style immutable classes with almost no boilerplate. Sealed classes make polymorphism exhaustive and compiler-checked. The four pillars remain the mental model; the syntax around them keeps getting leaner.
Take the notes with you
Everything on this page - pillars, diagrams, cheat sheet, roadmap - bundled into one file you can revisit anytime.