What Is Object-Oriented Programming?

Object-oriented programming organises a program around objects: bundles of data (state) together with the operations allowed to touch that data (behaviour). Rather than a program being a pile of functions that receive data, the data becomes the thing that answers questions about itself. A bank account that knows how to deposit, withdraw and report its balance is the canonical example, instead of scattered helpers each editing account fields directly.

Writing classes is not the same as writing object-oriented code, and that distinction is usually what an interviewer is probing. Procedural logic can be packaged inside classes and still pass data around as loose parameter lists. The object-oriented discipline is that objects communicate through a small public surface and each object guards its own state so no outsider can corrupt it.

public class Main {
    public static void main(String[] args) {
        Cart cart = new Cart();
        cart.add(new Item("Keyboard", 79.0));
        cart.add(new Item("Mouse", 25.0));
        System.out.println(cart.describe());
    }
}

class Cart {
    private final java.util.List<Item> items = new java.util.ArrayList<>();
    void add(Item item) { items.add(item); }
    String describe() { return items.size() + " item(s): " + items; }
}

class Item {
    private final String name;
    private final double price;
    Item(String name, double price) { this.name = name; this.price = price; }
    public String toString() { return name + " $" + price; }
}

Read the code for the discipline it models. The cart owns its list of items, so the only way to change that list is the add method and the only way to learn what is inside is describe. The item prints itself instead of the cart reaching into private fields to assemble a string. State is owned, behaviour is exposed, and internals stay free to change without breaking callers.

Be honest about the trade-off. Objects cost more to design and read than a flat function, so the style earns its keep when behaviour varies, state must stay consistent, or several parts of the system share the same domain logic. For a one-off calculation, a plain function is usually the better answer.

Java is called object-oriented because the language is built around classes and objects rather than around stand-alone procedures and shared global data. Every value you manipulate belongs to some class, and every class defines both the data an instance holds and the operations that instance supports. There is no separate procedural dialect of Java to fall back on.

Bundling state with behaviour means a type owns its data. If a cart holds a list of items, then add, remove and total live on the cart too, not in some utility class that reaches in and edits the list. That keeps related code together and puts the rules that protect the data next to the data itself, which is where the next maintainer will look.

Java is object-oriented rather than merely object-based because it supports the classic pillars as first-class language features: access modifiers that hide state, interfaces that describe contracts, inheritance that extends behaviour, and dispatch on the runtime type of a reference. Purely object-based languages give you objects and nothing else. Java gives you the full set of tools for reasoning about them.

The interview point is that object orientation in Java is a language-level commitment rather than a style suggestion. It is also not exclusive. Java keeps primitives and static methods for the cases where a stateful class would be the wrong shape, so the strongest answer acknowledges both halves instead of claiming the language forbids functions.

Do not defend object orientation as a religion. Start by agreeing with half of the objection. Objects genuinely do add ceremony: more files, more indirection, more layers to read through, and a real cost when the domain is simple enough that one function would do. Pretending otherwise is exactly what makes a candidate sound like they memorised a definition instead of using the style.

Then make the safety claim precise. The safety comes from one thing: state that only one place can change. When a class guards its own invariants, an invalid combination cannot be created from outside, because there is no public path that lets you build one. That removes a whole category of defect, and it is not a stylistic preference.

Give a concrete example rather than a slogan. A class that stores a date range and guarantees the end never precedes the start makes every caller correct by construction. A pair of loose fields plus helper methods elsewhere pushes that check onto every future caller, including the ones nobody has written yet.

Finish with the honest conclusion, because that is what experienced interviewers want to hear: use objects where state and behaviour belong together, and use plain functions where the problem is a transformation over values with no life of its own. The ceremony is worth it exactly when the model is doing work for you.