OOP Concepts in Java Explained with Examples

Quick Answer

OOP (Object-Oriented Programming) in Java is built on four pillars: encapsulation, inheritance, polymorphism and abstraction. Encapsulation hides an object's data behind methods, inheritance lets one class reuse another's fields and behaviour, polymorphism lets the same method call behave differently for different objects, and abstraction exposes only what a caller needs while hiding the details. Master these four with small examples and you can answer most Java OOP interview questions with confidence.

What are OOPs concepts in Java?

If you are preparing for placement drives or your first coding interview in India, the OOPs concepts in Java are almost guaranteed to come up. Interviewers like them because they reveal whether you can think in terms of objects, not just write loops.

OOP stands for Object-Oriented Programming — a way of writing code where you model real-world things (a bank account, a car, a payment) as objects. Each object bundles together its data and the methods that work on that data. You will often hear it called "OOPs" in Indian classrooms and interviews; the extra "s" is just habit, the meaning is the same.

Java is built around this idea from the ground up. Everything you write lives inside a class, and OOP rests on four pillars: encapsulation, inheritance, polymorphism and abstraction. Learn these four with small examples and you can explain most interview questions clearly. If Java itself is new to you, our free Java course covers the basics first.

Encapsulation: keep data safe

Encapsulation means keeping an object's data private and letting the outside world touch it only through controlled methods. Think of it like an ATM: you cannot reach in and change the cash directly; you go through buttons that check the rules first.

In Java you do this by marking fields private and exposing public methods (getters and setters):

public class BankAccount {
    private double balance;   // hidden state

    public BankAccount(double openingBalance) {
        this.balance = openingBalance;
    }

    public double getBalance() {
        return balance;
    }

    public void deposit(double amount) {
        if (amount > 0) {          // rule lives inside the class
            balance += amount;
        }
    }
}

Why it matters: nobody can set balance to a negative number from outside, because the check lives inside deposit. Gotcha: adding a getter and setter for every field with no validation is not real encapsulation — you have just made the field public the long way. Only expose what callers genuinely need.

Inheritance: reuse without copy-paste

Inheritance lets one class reuse the fields and methods of another instead of copy-pasting them. The child class (subclass) extends the parent (superclass) and automatically gets its behaviour, while adding its own.

class Vehicle {
    protected String brand;

    Vehicle(String brand) {
        this.brand = brand;
    }

    void start() {
        System.out.println(brand + " is starting");
    }
}

class Car extends Vehicle {
    Car(String brand) {
        super(brand);          // call the parent constructor
    }

    void openBoot() {
        System.out.println(brand + " boot is open");
    }
}

A Car object can call both start() (inherited) and openBoot() (its own). Why it matters: shared logic lives in one place, so a fix in Vehicle reaches every subclass. Gotcha: Java does not allow a class to extend two classes at once (to avoid the "diamond problem"). If you need behaviour from multiple sources, use interfaces. Also, do not over-use inheritance — if the relationship is not a genuine "is-a" (a Car is a Vehicle), prefer composition.

Polymorphism: one name, many forms

Polymorphism means "many forms" — the same method call can behave differently depending on the object. Java has two kinds.

Compile-time (overloading): same method name, different parameters.

int add(int a, int b) { return a + b; }
double add(double a, double b) { return a + b; }

Run-time (overriding): a subclass replaces a parent method with its own version. This is the type interviewers usually mean.

class Shape {
    double area() { return 0; }
}

class Circle extends Shape {
    private double r;
    Circle(double r) { this.r = r; }

    @Override
    double area() { return Math.PI * r * r; }
}

class Square extends Shape {
    private double side;
    Square(double side) { this.side = side; }

    @Override
    double area() { return side * side; }
}

// somewhere in main:
Shape[] shapes = { new Circle(2), new Square(3) };
for (Shape s : shapes) {
    System.out.println(s.area());   // 12.566... then 9.0
}

Why it matters: you can write code against Shape and it works for every current and future shape. Gotcha: static and private methods are not overridden — they are resolved by the reference type, not the object, which trips up many candidates.

Abstraction: hide the messy details

Abstraction means showing only what a caller needs and hiding how it actually works. When you pay with an app, you tap "Pay" — you do not care whether it runs UPI, card or netbanking code underneath.

In Java you express abstraction with an interface or an abstract class. An interface says what must be done, and each class decides how:

interface Payment {
    void pay(double amount);        // no body, just the contract
}

class UpiPayment implements Payment {
    @Override
    public void pay(double amount) {
        System.out.println("Paid Rs " + amount + " via UPI");
    }
}

class CardPayment implements Payment {
    @Override
    public void pay(double amount) {
        System.out.println("Paid Rs " + amount + " via card");
    }
}

Code that holds a Payment reference can call pay() without knowing which class it really is. Gotcha: people confuse abstraction with encapsulation. Encapsulation is about hiding data (the private keyword); abstraction is about hiding complexity behind a simple contract (interfaces and abstract classes). They work together but solve different problems.

The four pillars at a glance

Here is the whole picture in one place — a handy revision table for the night before an interview:

Common interview gotchas

These are the mistakes that cost marks in interviews and cause bugs in real projects:

• Confusing abstraction and encapsulation. Remember: encapsulation hides data, abstraction hides complexity.
• Thinking Java has multiple class inheritance. It does not — a class extends exactly one class but can implement many interfaces.
• Assuming static methods are polymorphic. They are not overridden; this is called method hiding.
• Writing getters and setters for everything. That quietly defeats encapsulation. Expose only what is needed.
• Overusing inheritance. If it is not a real "is-a" relationship, use composition (hold an object as a field) instead.
• Forgetting @Override. It is optional, but it makes the compiler catch typos in your method signature for you.

How to practice and remember them

Reading about the four pillars is not enough — you remember them by typing them. Here is a simple plan:

1. Recreate the four examples above from memory, running each one.
2. Model something from your own life as classes — a college Student, a Library, a FoodOrder — and apply all four pillars.
3. For every class, ask: what data should be private? what can be reused by a subclass? where would an interface make swapping easy?
4. Practise explaining each pillar out loud in one sentence, as if to an interviewer.

Our free, hands-on Java course builds these concepts step by step with exercises, so you are not just memorising definitions but writing real object-oriented code. Do that for a week and OOP stops being an interview topic to fear and becomes the natural way you structure programs.

Frequently Asked Questions