Object-Oriented Programming (OOP)

Picture a bank: every account has a balance, and a short list of things you are allowed to do with it — deposit, withdraw, check the total. Object-oriented programming takes exactly that picture and turns it into code structure. The balance and the rules for changing it live together in one place, the way they do in the real account.

Object-oriented programming, or OOP, is a way to organize code around objects. An object keeps related data and the methods that work on that data together, so a program can model bank accounts, shopping carts, or game characters more directly. At its center are two terms: a class describes what something should contain and what it can do; an object is one actual instance created from that class.

What a Class and an Object Really Are

Think of a class as a blueprint and an object as a real thing built from it. A BankAccount class might define a balance plus methods like deposit and withdraw. Alice's account and Bob's account are two separate objects that follow the same rules but hold different balances. This is why OOP is said to bundle state (the data an object stores) and behavior (the actions it allows).

Here is the core idea in code:

class BankAccount {
  constructor(public owner: string, private balance = 0) {}

  deposit(amount: number) {
    if (amount <= 0) throw new Error('amount must be positive');
    this.balance += amount;
  }

  withdraw(amount: number) {
    if (amount <= 0) throw new Error('amount must be positive');
    if (amount > this.balance) throw new Error('insufficient funds');
    this.balance -= amount;
  }

  getBalance() {
    return this.balance;
  }
}

Create new BankAccount('Alice', 100) and new BankAccount('Bob', 100) and those objects share the same class but keep separate balances — that is the practical class-versus-object difference. The example also shows encapsulation: outside code cannot change balance directly; it must go through deposit and withdraw, which enforce the rules.

The Three Ideas Behind OOP

• Encapsulation: keep data and the methods that manage it together.
• Inheritance: let one class reuse or extend another when there is a true "is a" relationship.
• Polymorphism: let different objects respond to the same method name in different ways.

These are useful, but they are secondary to the basic question: does this program naturally consist of objects with their own state and behavior? OOP helps when a program has clear entities with their own rules — if the balance belongs to the account, the code that changes the balance usually belongs there too, which makes responsibilities easy to locate.

Where OOP Fits and Where It Doesn't

OOP is common in business software, games, simulations, and user interfaces. It fits when the program tracks entities that persist over time and follow clear rules. If the task is a short script or a pipeline that mostly transforms data step by step, OOP can add more structure than you need, and plain functions may read more easily. The best style depends on the shape of the problem, not on a rule that everything must be a class.

A quick test for whether OOP fits, asked as two questions:

1. What are the main things this program needs to represent?
2. What state and behavior naturally belong to each thing?

If those answers are clear, OOP may help. If they are not, forcing everything into classes makes code harder to understand, not easier.

Concepts Students Often Confuse

A frequent confusion is mistaking a class for an object — the class is the template, the object is one actual thing built from it. Another is overusing inheritance: it helps when one class is genuinely a specialized form of another, but long inheritance chains make code rigid and hard to change, and combining small objects is often simpler. A third is treating OOP as a rule rather than a tool — some problems are easier with plain functions and simple data structures.

Make It Concrete

Design a small system you already understand, such as a to-do list or a library checkout. Name the main objects, decide what data each one should own, and decide which methods are allowed to change that data. Then sketch the same thing with plain functions and compare. Holding the two designs side by side is the fastest way to feel when grouping state and behavior into objects actually earns its keep — and when it just gets in the way.