OOP Concepts Explained: Object-Oriented Programming in Java and Python

Most beginners meet object-oriented programming as a list of four scary words. They're simpler than they sound. OOP is just a way to keep related data and behaviour together, so a large program stays understandable as it grows. This guide explains every idea with one running analogy, a restaurant kitchen, then shows each one in a few lines of Python, and finally all four together in Java. No prior OOP knowledge is assumed: if you can write a function and a variable, you can follow along.

OOP in One Sentence

Object-oriented programming means building a program out of objects, where each object holds some data and knows how to do things with it. Compare that with a purely procedural style, where data sits in variables and separate functions pass it around. Both work. OOP pays off when a program models many related things (users, orders, payments, chefs) and you want each one's rules to live in one place.

Almost every mainstream language supports OOP: Java and C# are built around it, Python, JavaScript, PHP and C++ support it alongside other styles.

Classes and Objects: The Recipe and the Dish

A class is a blueprint. It says what data every object of that kind has (its attributes) and what it can do (its methods). An object, also called an instance, is one concrete thing built from the class, with its own values.

Below, Dish is the recipe. pasta and salad are two separate objects made from it. They share the same structure and methods, but each keeps its own name and price.

class Dish:
    """The recipe: what every dish has and can do."""

    def __init__(self, name, price):
        self.name = name        # data the object carries
        self.price = price

    def describe(self):         # behaviour the object can perform
        return f"{self.name} costs ${self.price:.2f}"


# Objects: real dishes made from the same recipe
pasta = Dish("Pasta", 12.5)
salad = Dish("Salad", 8)

print(pasta.describe())
print(salad.describe())
print(pasta is salad)           # two separate objects

Encapsulation: The Kitchen Door

Encapsulation means an object protects its own data and only lets the outside world change it through methods that enforce the rules. Customers can order food, but they can't walk into the kitchen and change the recipe.

Here an Order keeps its list of items internal. The only way to add an item is add(), which rejects negative prices, and the total is read-only because it's always calculated from the items.

class Order:
    def __init__(self):
        self._items = []        # leading underscore: internal, don't touch

    def add(self, name, price):
        if price <= 0:
            raise ValueError("price must be positive")
        self._items.append((name, price))

    @property
    def total(self):            # read-only view, computed from the items
        return sum(price for _, price in self._items)


order = Order()
order.add("Pasta", 12.5)
order.add("Salad", 8)
print("Total:", order.total)

try:
    order.add("Free lunch", -5)
except ValueError as e:
    print("Rejected:", e)

try:
    order.total = 0             # no setter, so this is blocked
except AttributeError:
    print("Can't overwrite the total directly")

Inheritance: A Pastry Chef Is Still a Chef

Inheritance lets a new class (the child or subclass) start from an existing one (the parent or base class). The child gets everything the parent has and only adds or changes what's different. A pastry chef greets people like any chef but cooks something different.

Use inheritance only for a true 'is a' relationship: a PastryChef is a Chef. If you're tempted to inherit just to reuse a few methods, composition (one object holding another) is usually the better choice.

class Chef:
    def __init__(self, name):
        self.name = name

    def greet(self):
        return f"Hi, I'm {self.name}"

    def cook(self):
        return "cooks a main course"


class PastryChef(Chef):          # a PastryChef IS a Chef
    def cook(self):              # override just the part that differs
        return "bakes a tart"


anna = PastryChef("Anna")
print(anna.greet())              # inherited from Chef, not rewritten
print(anna.cook())               # its own version
print(isinstance(anna, Chef))

Polymorphism: Everyone Responds to "Cook"

Polymorphism means 'many forms': the same method call does the right thing for each kind of object. The head chef shouts "cook!" once, and every chef makes their own dish. The code giving the order doesn't need to know which kind of chef it's talking to.

This is what removes long if/elif chains that check an object's type. Add a new kind of chef with its own cook() method and the loop below keeps working without a single change.

class Chef:
    def cook(self):
        return "main course"

class PastryChef(Chef):
    def cook(self):
        return "lemon tart"

class SushiChef(Chef):
    def cook(self):
        return "salmon nigiri"


kitchen = [Chef(), PastryChef(), SushiChef()]
for chef in kitchen:
    # Same call, different behaviour: the caller doesn't check types
    print(type(chef).__name__, "->", chef.cook())

Abstraction: The Menu Hides the Kitchen

Abstraction means depending on what something can do, not how it does it. A menu lists dishes without explaining the cooking. In code, an abstract base class (or an interface in Java) defines the methods every implementation must provide, and the rest of the program works only with that contract.

Below, checkout() accepts any PaymentMethod. It doesn't know or care whether it's a card or cash. The abstract class itself can't be created, which forces every real payment type to implement pay().

from abc import ABC, abstractmethod


class PaymentMethod(ABC):
    """The menu: what any payment must offer, not how it works."""

    @abstractmethod
    def pay(self, amount): ...


class Card(PaymentMethod):
    def pay(self, amount):
        return f"Charged {amount} to card"


class Cash(PaymentMethod):
    def pay(self, amount):
        return f"Took {amount} in cash"


def checkout(method: PaymentMethod, amount):
    return method.pay(amount)    # works for any PaymentMethod


print(checkout(Card(), 20.5))
print(checkout(Cash(), 8))

try:
    PaymentMethod()
except TypeError:
    print("Can't create the abstract menu itself")

All Four Pillars Together in Java

Java makes the same ideas explicit with keywords: interface for abstraction, private for encapsulation, extends for inheritance and @Override for polymorphism. This small kitchen uses all four in one file.

import java.util.List;

public class Kitchen {

    // Abstraction: the contract every chef follows
    interface Cook {
        String cook();
    }

    // Encapsulation: name is private and can't be changed after creation
    static class Chef implements Cook {
        private final String name;

        Chef(String name) { this.name = name; }

        public String getName() { return name; }

        public String cook() { return "main course"; }
    }

    // Inheritance: a PastryChef is a Chef and overrides one behaviour
    static class PastryChef extends Chef {
        PastryChef(String name) { super(name); }

        @Override
        public String cook() { return "lemon tart"; }
    }

    public static void main(String[] args) {
        List<Chef> chefs = List.of(new Chef("Ravi"), new PastryChef("Anna"));
        for (Chef c : chefs) {
            // Polymorphism: the same call runs the right version
            System.out.println(c.getName() + " makes " + c.cook());
        }
    }
}

When OOP Is the Wrong Tool

OOP isn't always the best fit. A short script that reads a file and prints a report is clearer as a few functions. Data transformations, such as cleaning a list of records, are often simpler in a functional style with plain functions and immutable data. Overusing OOP shows up as classes with one method, getters and setters for everything, and deep inheritance trees that make a small change ripple everywhere.

A good rule: introduce a class when you have data and behaviour that genuinely belong together, or several kinds of thing that share a contract. Otherwise, a function is fine.