Top 60 OOPs Interview Questions (2026)

OOPs is a way of structuring code around objects that bundle data with the methods that act on it. Instead of scattered functions passing values around, you group related state and behavior into classes and create objects from them.

The goal is code that maps to the real world: a BankAccount object holds a balance and knows how to deposit and withdraw. This keeps related things together, hides internal detail, and makes large systems easier to reason about.

Encapsulation, abstraction, inheritance, and polymorphism. Encapsulation bundles data with methods and hides internal state. Abstraction exposes what an object does, not how. Inheritance lets a class reuse and extend another. Polymorphism lets one interface drive many behaviors.

Being able to define each and give a real example is the bar. Most OOPs rounds open here and branch out from your answer.

A class is a blueprint that defines structure (fields) and behavior (methods). An object is a concrete instance created from that class, with its own copy of the state.

One Car class can produce many Car objects, each with a different color and speed. The class is the design; objects are the things you actually work with at runtime.

Encapsulation bundles data and the methods that operate on it inside one unit, and hides the internal state behind a public interface. Callers change state through methods, not by touching fields directly.

You do it by making fields private and exposing controlled getters and setters. That lets you validate input, keep invariants, and change the internals later without breaking callers.

Abstraction exposes what an object does while hiding how it does it. You drive a car with a pedal and steering wheel without knowing the engine internals. In code, abstract classes and interfaces define a contract and leave the implementation to subclasses.

The distinction from encapsulation: abstraction is about design (what to expose at the interface), encapsulation is about implementation (hiding and protecting state). They work together but answer different questions.

Inheritance lets a class (the child or subclass) reuse and extend another class (the parent or superclass). The child gets the parent's fields and methods and can add its own or override existing ones.

It models an is-a relationship: a Dog is an Animal, so Dog extends Animal and inherits eat() while adding bark(). The payoff is code reuse; the risk is tight coupling to the parent, which is why deep hierarchies are discouraged.

Polymorphism means one interface driving many behaviors. The same method call resolves to different implementations depending on the actual object's type. A draw() call on a Shape reference runs Circle.draw() or Square.draw() based on what the object really is.

It comes in two forms: compile-time (method overloading, same name different parameters) and runtime (method overriding, a subclass replacing a parent method). Runtime polymorphism is what makes flexible, extensible designs possible.

Overloading is two or more methods with the same name but different parameter lists in the same class, resolved at compile time. Overriding is a subclass providing its own version of a method it inherited, with the same signature, resolved at runtime.

Overloading is a convenience (one name, several argument shapes). Overriding is the mechanism behind runtime polymorphism.

A constructor is a special method that runs when an object is created, setting up its initial state. It shares the class name and returns no value, not even void.

If you write none, most languages provide a default no-argument constructor. Once you add any constructor, that free default disappears unless you write it yourself.

Three common kinds: a default (no-argument) constructor that sets fields to defaults, a parameterized constructor that takes arguments to initialize state, and a copy constructor that builds a new object from an existing one.

Not every language names all three (Java has no built-in copy constructor; you write one), but the concepts carry across.

A destructor is a method that runs when an object is destroyed, used to release resources it held, such as memory, file handles, or connections. In C++ it's ~ClassName() and runs deterministically when the object goes out of scope.

Languages with garbage collection (Java, Python) don't use classic destructors the same way. Java has no reliable destructor; Python's __del__ exists but timing isn't guaranteed, so both prefer explicit cleanup like try-with-resources or context managers.

Access modifiers control who can see a class member. The common set is public (accessible everywhere), private (only inside the class), and protected (the class plus its subclasses). Java adds a package-private default when you write no modifier.

They're the tool that makes encapsulation real: mark state private, expose behavior public, and callers can't reach past your interface.

this refers to the current object, the instance whose method is running. It disambiguates a field from a parameter of the same name (this.x = x), passes the current object to another method, or chains constructors.

In Python the same role is filled by an explicit self parameter, which is why Python methods list self first.

A static member belongs to the class itself, not to any single object. One copy is shared across all instances, and you access it through the class name. A static counter shared by every object, or a utility method that needs no instance state, are the usual cases.

A static method can't use this or instance fields, because there's no particular object to refer to. That restriction is the whole point.

An abstract class is a class you can't instantiate directly. It can hold both concrete methods (shared implementation) and abstract methods (no body) that subclasses must implement. It exists to be extended.

Use one when several classes share behavior and state but also need their own version of some methods. A Shape base class with a concrete describe() and an abstract area() is the classic example.

An interface is a contract: a set of method signatures a class promises to implement, with no state and (traditionally) no implementation. It says what a type can do without saying how.

A class can implement many interfaces, which is how languages like Java get the flexibility of multiple inheritance without its ambiguity. Interfaces are the backbone of loose coupling: code depends on the contract, not the concrete class.

An is-a relationship is inheritance: a Dog is an Animal, so Dog extends Animal. A has-a relationship is composition: a Car has an Engine, so Car holds an Engine object as a field.

The rule of thumb: reach for inheritance only when the subclass truly is a specialized parent; otherwise compose. Misusing inheritance for code reuse is one of the most common design mistakes.

Getters and setters are methods that read and write a private field. They're the controlled doorway to encapsulated state: a setter can validate input, a getter can compute or format on the way out.

The real reason to use them isn't ceremony, it's future-proofing. a plain field, and if validation or logging is needed later, add it inside the accessor without changing a single caller comes first.

Single (one child, one parent), multilevel (a chain: C extends B extends A), hierarchical (many children share one parent), and multiple (one child, several parents). Multiple inheritance of classes is where languages diverge: C++ allows it, Java forbids it for classes but allows multiple interfaces.

Knowing which your target language supports matters, because the ambiguity from multiple class inheritance (the diamond problem) is a common follow-up.

super refers to the parent class. It calls the parent's constructor (super(args)) or invokes a parent method that the subclass has overridden (super.method()), so you can extend behavior instead of fully replacing it.

Calling super() in a constructor is how a subclass makes sure the parent's initialization runs before its own.

An abstract class can hold state (fields) and concrete methods that subclasses inherit; a class extends only one of them. An interface is a pure contract of method signatures with no state, and a class can implement many.

Choose an abstract class when subclasses share code and state and form an is-a family. Choose an interface when unrelated classes need to promise the same capability. Modern Java blurs this a little with default methods on interfaces, worth mentioning as a nuance.

Inheritance couples a subclass tightly to its parent's implementation: a change in the base can quietly break every child, and deep hierarchies become rigid. Composition assembles behavior from smaller parts a class holds, so you can swap and combine capabilities without a fragile family tree.

The guideline 'favor composition over inheritance' doesn't ban inheritance; it says reach for it only when there's a true is-a relationship, and prefer has-a assembly the rest of the time.

Compile-time (static) polymorphism is method overloading: the compiler picks the method from the argument types before the program runs. Runtime (dynamic) polymorphism is method overriding: the actual object's type decides which method runs, resolved during execution through a mechanism like a virtual method table.

Runtime polymorphism is the one that gives OOPs its flexibility, because you can add new subclasses and existing code calls the right method without changing.

The diamond problem happens when a class inherits from two classes that share a common ancestor. If both middle classes override a method, the bottom class faces ambiguity about which version it inherits, and the shared ancestor's state can be duplicated.

Languages solve it differently: C++ uses virtual inheritance to share one copy of the ancestor, Java sidesteps it by forbidding multiple class inheritance (interfaces don't carry state, so no ambiguity), and Python resolves method order with a defined MRO.

A virtual function is one whose call resolves to the object's actual type at runtime, not the reference type. In C++ you mark it virtual; in Java methods are virtual by default. This is what makes overriding work: a Shape reference pointing to a Circle calls Circle.draw().

Under the hood, each class with virtual methods has a table of function pointers (a vtable), and each object carries a pointer to its class's table. The call looks up the right function through that table, which is why it's called dynamic dispatch.

Five design guidelines for maintainable OOPs code. Single Responsibility: a class should have one reason to change. Open/Closed: open for extension, closed for modification. Liskov Substitution: a subclass must be usable wherever its parent is. Interface Segregation: prefer small focused interfaces over fat ones. Dependency Inversion: depend on abstractions, not concrete classes.

Interviewers rarely want all five recited; they want you to spot a violation and fix it. Being able to The principle a piece of bad code breaks is the real test.

Take a payment processor. Abstraction is the interface: a pay(amount) method that callers use without knowing whether it's Stripe or PayPal underneath. That's the design decision about what to expose.

Encapsulation is inside the implementation: the Stripe class keeps its API key and retry counter private and validates the amount before charging. That's protecting and hiding the state. Same class, two different ideas working together.

Binding is matching a method call to its definition. Static (early) binding happens at compile time, used for private, static, final, and overloaded methods where the target is known without running the program. Dynamic (late) binding happens at runtime for overridden methods, where the object's real type decides.

The distinction explains a common gotcha: a variable's declared type drives overload resolution (static), but its actual object drives override resolution (dynamic).

Coupling measures how much one class depends on another; cohesion measures how focused a single class is on one job. Good design aims for low coupling (classes change independently) and high cohesion (each class does one thing well).

High coupling means a change ripples across many classes. Low cohesion means a class does too many unrelated things and is hard to name. You reduce coupling with interfaces and dependency injection, and raise cohesion by splitting bloated classes.

All three describe how objects relate. Association is a general link (a Teacher uses a Classroom). Aggregation is a weak has-a where the part can outlive the whole (a Team has Players, but players exist without the team). Composition is a strong has-a where the part's lifetime is tied to the whole (a House has Rooms; destroy the house and the rooms go with it).

The lifetime question is the deciding line: does the part survive without the whole?

Method hiding happens with static methods: a subclass declares a static method with the same signature as the parent's, and which one runs depends on the reference type, not the object. Overriding is for instance methods and depends on the object's actual type.

The practical warning: hiding looks like overriding but behaves differently, so calling a hidden static method through a parent reference runs the parent's version. It's a frequent trick question.

final locks something down. A final field can't be reassigned after initialization, a final method can't be overridden, and a final class can't be extended. It communicates intent and lets the compiler optimize.

You'd make a class final to prevent subclassing that could break invariants (String is final in Java), and a method final to stop subclasses from changing behavior the base relies on.

Constructor chaining is one constructor calling another so initialization logic lives in one place. Within a class you chain with this(args); to a parent you chain with super(args). A parameterized constructor can delegate to a fuller one that does the real setup.

It avoids duplicating field assignments across overloaded constructors. The chain always runs the parent constructor first, then works down.

A shallow copy duplicates the object's top-level fields but shares any referenced sub-objects: copying an Order copies the reference to its Customer, so both orders point to the same customer. A deep copy recursively duplicates the referenced objects too, giving a fully independent tree.

The classic bug is mutating a nested object through what you assumed was an independent copy. Deep copy when the object owns its sub-objects; shallow copy when sharing is fine.

Dependency injection means a class receives its collaborators from outside (through the constructor or a setter) instead of creating them itself. A ReportService is handed a Database rather than doing new Database() internally.

It's the practical form of the Dependency Inversion principle: the class depends on an abstraction it's given, which makes it easy to swap a real database for a fake in tests and cuts coupling.

An immutable object can't change after construction: all fields are set once and never reassigned. String in Java and tuples in Python are immutable. You build one by making fields final/private, providing no setters, and returning copies of any mutable internals.

The payoff is safety: immutable objects are inherently thread-safe, can be shared freely without defensive copying, and make great map keys because their hash never changes.

It lets you write code against a general type and add new specific types without changing that code. A renderer that loops over a list of Shape and calls draw() works for Circle, Square, and any future shape, no if-else on type needed.

That's the open/closed principle in action: the drawing loop is closed for modification but open to new shapes. Without polymorphism you'd have a growing switch statement that every new type forces you to edit.

Cloning creates a copy of an existing object. Java's Cloneable and clone() give a shallow copy by default, which shares mutable sub-objects and surprises people. Many teams avoid clone() entirely in favor of copy constructors or factory methods that make the copy semantics explicit.

The pitfalls: shallow copies sharing nested state, clone() bypassing constructors so invariants can be skipped, and inconsistent behavior across a class hierarchy. Being aware of these is the intermediate-level signal.

Upcasting treats a subclass object as its parent type (Animal a = new Dog()); it's always safe and implicit. Downcasting goes the other way (Dog d = (Dog) a), treating a parent reference as a subclass, and it's only safe if the object really is that subclass, otherwise you get a runtime error.

Before downcasting, check with instanceof. Frequent downcasting is often a smell that polymorphism should be doing the work instead.

The overriding method needs the same name and parameter list, a return type that's the same or a subtype (covariant return), and access that's the same or more permissive, not narrower. It can't throw broader checked exceptions than the parent declares.

Break any of these and it's no longer an override: it becomes an overload, a compile error, or silent method hiding. The @Override annotation exists to catch these mistakes at compile time.

Design patterns are reusable solutions to common design problems, named so teams can discuss them quickly. The classic groups are creational (Factory, Singleton, Builder), structural (Adapter, Decorator, Facade), and behavioral (Observer, Strategy, Command).

The production signal isn't reciting the catalog; it's naming a pattern you actually used and why. Strategy to swap algorithms at runtime, Observer for event notification, Factory to decouple creation from use. Pair each with a real problem it solved.

A singleton guarantees one instance and a global access point: a private constructor, a static holder, and a static accessor. In a threaded context you need lazy initialization done safely, and the initialization-on-demand holder idiom (or an enum in Java) handles that cleanly.

The downsides are real: singletons act as global state, hide dependencies, and make testing hard because you can't easily substitute them. Many teams treat overuse of singletons as a design smell and prefer dependency injection with a single configured instance.

A Factory decides which class to instantiate and hides that choice from the caller: you ask for a Shape and get back a Circle or Square based on input. A Builder assembles one complex object step by step, useful when a constructor would have many parameters or optional fields.

Rule of thumb: Factory for choosing a type, Builder for constructing a single object with many configuration options. They solve different problems and sometimes appear together.

The classic one is Square extends Rectangle. A Rectangle lets you set width and height independently; a Square forces them equal. Code that sets a Rectangle's width to 5 and height to 4 expecting area 20 breaks when handed a Square, which silently changes both dimensions.

The fix is to not model it as inheritance: Square and Rectangle share a Shape interface with area(), rather than Square pretending to be a substitutable Rectangle. LSP violations show up as subclasses that surprise code written for the parent.

You design so new behavior is added by writing new classes, not editing existing ones. Instead of a discount() method with a growing switch over customer types, define a DiscountStrategy interface and add a new strategy class per rule. The pricing code never changes when a new discount appears.

The trade-off worth naming: over-abstracting for changes that never come adds complexity. Apply Open/Closed where variation is real and expected, not everywhere on principle.

Subclassing to vary one behavior explodes the class count and locks the choice in at compile time: a SortAscending and SortDescending subclass, then variants for every combination. Strategy pulls the varying behavior into its own interface, injected as an object, so you swap it at runtime and combine freely.

It's composition over inheritance applied to algorithms. The object holds a strategy field instead of being a specific subclass, which keeps the hierarchy flat and the behavior interchangeable.

Circular dependencies (A needs B, B needs A) signal that responsibilities are tangled. The usual fixes: extract the shared logic into a third class both depend on, invert one direction with an interface so A depends on an abstraction B implements, or merge the two if they're really one concept.

In frameworks with dependency injection, circular constructor dependencies fail at startup, which is a useful forcing function. Setter injection or a mediator can break the cycle, but the cleaner design is usually to rethink the boundaries.

A God object is a class that knows and does too much: hundreds of methods, many unrelated responsibilities, touched by every change. It violates single responsibility and becomes a merge-conflict magnet and a testing nightmare.

You refactor by identifying cohesive clusters of methods and fields, then extracting each into its own focused class, wiring them back through composition. Do it incrementally with tests as a safety net, because a big-bang rewrite of a central class is risky.

Default methods let an interface ship a method body, so you can add a method to a widely-implemented interface without breaking every implementer. That's how Java evolved the Collection interfaces without a mass migration.

They complicate the abstract-class-versus-interface line and reintroduce a mild multiple-inheritance ambiguity: if two interfaces provide the same default method, the implementing class must resolve it explicitly. Used sparingly for evolution they're fine; used to stuff logic into interfaces they blur design.

When applied dogmatically to code that doesn't need it. Splitting every class to satisfy single responsibility can scatter simple logic across ten files. Adding interfaces for dependency inversion where there's only ever one implementation is indirection with no payoff.

The senior view treats SOLID as a response to actual change and pain, not a checklist. You reach for an interface when a second implementation is real or imminent, not preemptively. Naming that trade-off is what separates experience from principle-recitation.

Loose coupling and dependency injection make code testable: if a class receives its collaborators, you pass fakes in tests. Tight coupling, static calls, and singletons make it hard because you can't substitute behavior. Small, single-responsibility classes are easier to test than God objects.

So testability is a design feedback signal. If a class is painful to test, that pain usually points at a coupling or responsibility problem worth fixing, not just a missing mock.

A leaky abstraction is one whose underlying detail forces itself on callers despite the interface trying to hide it. An ORM abstracts SQL until a performance problem makes you reason about the exact queries it generates; the SQL leaks through.

You can't eliminate leaks entirely (all non-trivial abstractions leak somewhat), so you manage them: document the leak, provide an escape hatch (a way to drop to raw queries), and don't pretend the abstraction is total. Pretending it's leak-free is where teams get burned.

With value semantics, assigning or passing an object copies it, so changes don't propagate. With reference semantics, you share a handle to one object, so a mutation is visible everywhere it's referenced. Most OOPs languages use reference semantics for objects, which is why aliasing bugs happen.

It matters for equality (== on references compares identity, not content, so you override equals/hashCode), for defensive copying at boundaries, and for the case for immutable objects, which sidestep the whole aliasing problem.

Keep it shallow. Each level of inheritance couples subclasses to more ancestor behavior, and deep trees become rigid and hard to trace. A good target is one or two levels, with composition doing the rest of the work.

The heuristic: inherit only for true is-a relationships where the subclass is genuinely substitutable, and where the shared behavior is stable. If you're inheriting mainly to reuse code, that's a signal to compose instead. Depth for its own sake is a smell.

By returning a reference to a mutable internal object. A getItems() that hands back the actual internal list lets callers mutate your object's state directly, bypassing every validation and invariant the class tried to protect.

The fix is to return a copy or an unmodifiable view. This is the difference between exposing data and exposing a controlled read, and it's a frequent source of subtle bugs in otherwise well-encapsulated classes.

Replace a type-based switch or if-else chain with polymorphism when the same branching logic appears in several places and new types are added often; each new type then means one new class instead of edits scattered across the codebase.

Don't do it for a one-off conditional, simple value comparisons, or logic that isn't type-driven. Turning every if into a class hierarchy is over-engineering that hurts readability. The trigger is repeated type-switching, not conditionals in general.

Deep inheritance couples applications to framework internals: a base class you must extend dictates your structure and breaks you on framework upgrades. Composition and interfaces let the framework offer capabilities you plug in, so your code depends on small contracts, not a fragile parent.

This is why patterns shifted from extend-our-base-class toward implement-this-interface and annotation-driven wiring. It keeps the framework's evolution and your code loosely joined, which matters a lot across version upgrades.

Mixins (Python, Ruby) and traits (Scala, Rust) let you compose reusable behavior into a class without classic single-parent inheritance. A class can pull in several small units of behavior, giving code reuse across unrelated hierarchies.

They solve the reuse problem that single inheritance can't: sharing a capability like serialization or comparison across classes that don't share a parent. The risk is method-resolution complexity when several mixins define the same name, so languages define a clear resolution order.

Decide extension points on purpose: mark the methods meant to be overridden, make everything else final or private, and document the contract each overridable method must honor. Never call an overridable method from a constructor, because the subclass override runs before the subclass is fully initialized.

The principle behind it: design and document for inheritance, or prohibit it. A class that's accidentally extensible, with no thought to which methods are safe to override, breaks in surprising ways when someone subclasses it.

Start from the nouns and their behavior, not a class diagram. A ParkingLot holds Levels; each Level has ParkingSpots of types (compact, large, handicapped); a Vehicle (with subtypes) needs a spot that fits; a Ticket tracks entry time; a pricing strategy computes the fee. Encapsulate spot availability inside Level so nothing else mutates it directly.

Then The design choices out loud: composition for lot-has-levels, an interface for pricing so it's swappable, polymorphism so any Vehicle subtype fits the parking logic. The interviewer is scoring your process, clarify requirements, find entities, assign responsibilities, choose relationships, more than the exact classes.