Top 50 OOP Interview Questions with Real-Life Examples

A programming paradigm that organizes code around objects — bundles of data (fields) and behavior (methods) that model real-world things. Instead of writing one long sequence of instructions, you describe entities and how they interact.

Encapsulation (bundle data + methods, hide internals), Abstraction (expose what, hide how), Inheritance (derive new classes from existing ones), and Polymorphism (one interface, many forms). Together they enable modularity and reuse.

Procedural focuses on FUNCTIONS that operate on data passed around. OOP groups data + functions together into OBJECTS that own their state. Procedural is 'verb-first' (do this, then that); OOP is 'noun-first' (here's a User, ask it to do things).

Code reuse via inheritance, easier maintenance (changes localized), better modeling of real-world entities, encapsulation prevents accidental misuse, and clear class boundaries support large-team collaboration.

More boilerplate, slower for tiny scripts, easy to over-design with too many classes, and deep inheritance trees become fragile. Pure functions are sometimes simpler than wrapping everything in a class.

No. Data pipelines, scripts and numerical computing often work better with functional or procedural styles. OOP shines when you have many entities with stateful behavior — games, GUI apps, business domains.

Java, C#, C++, Python, Ruby, Kotlin, Swift. Some (Python, JavaScript, Ruby) are multi-paradigm — they support OOP but don't force it. C++ supports OOP, procedural AND generic programming side by side.

A blueprint that defines the structure (fields) and behavior (methods) of objects. A class itself doesn't store data — it describes what objects of that type look like.

An instance of a class — a concrete entity in memory with its own values for the class's fields. Many objects can exist from one class, each with independent state.

Class is the definition (the plan). Object is the actual thing (the result). One class, many objects. The class lives in code; objects live in memory at runtime.

A special method that runs automatically when an object is created. Its job is to initialize the object's fields and acquire resources. Often takes parameters to set initial values.

A method that runs when an object is destroyed (out of scope or explicitly deleted). It releases resources — closes files, frees memory, disconnects sockets. Not all languages have explicit destructors (Java uses garbage collection).

A constructor has the SAME name as the class, has NO return type and runs only once at object creation. A regular method has any name, can be called many times and explicitly returns values.

Inside a method, `this` refers to the CURRENT object — the instance the method was called on. Used to disambiguate parameter names from fields, and to pass the object to other methods.

Yes — through constructor overloading. Multiple constructors with different parameter lists. The compiler picks the right one based on the arguments you pass. Lets you create the same object in different ways.

Bundling data (fields) and the methods that operate on them into a single unit (class), AND restricting direct access to some of them. The object controls how its state is read and changed.

Keywords (public, private, protected) that control where a field or method can be used from. They enforce encapsulation by restricting visibility.

Public — accessible from anywhere. Private — only inside the same class. Protected — same class plus its subclasses. Use private by default and expose only what callers truly need.

To control access to private fields. Getters return the value (often with validation or formatting), setters change it (with validation or side effects like logging). You can later change internals without breaking callers.

Hiding internal data behind methods, so external code can't tamper with state directly. It's the safety benefit of encapsulation — the object guarantees its own invariants.

Encapsulation HIDES INTERNAL STATE — how the data is stored. Abstraction HIDES COMPLEXITY — what the operation actually does. Encapsulation is about access control; abstraction is about simplifying the interface.

Any device with a public interface and hidden internals: ATMs, microwaves, washing machines, controllers. You interact through buttons and a screen; the wiring, sensors and logic are inaccessible — by design.

A mechanism where one class (child / subclass) reuses and extends another (parent / superclass). The child gets the parent's fields and methods, and can add new ones or override existing ones.

Single (one parent), multi-level (A → B → C chain), multiple (two parents), hierarchical (one parent, many children) and hybrid (combinations). Not all languages support multiple inheritance (Java doesn't; C++ does).

A child class has exactly ONE parent class. The simplest and most common form — clear hierarchy, no ambiguity, supported in every OOP language.

A child class has TWO or more parent classes. Powerful but can cause ambiguity (which parent's method to use?). Supported in C++ and Python; not in Java/C# (they use interfaces instead).

A chain: class C extends B, and B extends A. Each level adds something. Useful but deep chains become brittle — any base-class change ripples down through every descendant.

When a class inherits from two classes that both inherit from a common ancestor, the child has TWO COPIES of the ancestor's members — ambiguity about which to use. Solved with virtual inheritance (C++) or by avoiding multiple inheritance entirely.

'is-a' = inheritance (a Dog IS-A Mammal). 'has-a' = composition (a Car HAS-A Engine). Choose inheritance when the child genuinely IS a kind of the parent; choose composition when it just owns or uses another thing.

When the relationship isn't truly 'is-a', when the parent might change frequently (breaking children), or when composition would be more flexible. The principle is 'favor composition over inheritance' — looser coupling, easier to test, less fragile.

'Many forms' — the ability for one interface to invoke different implementations depending on the actual type at runtime, or different method signatures at compile time. Same name, different behaviors.

The compiler decides which method to call based on static type, argument count or types. Achieved via method overloading and operator overloading. Resolved before the program runs — no runtime cost.

The decision happens at runtime based on the ACTUAL object type, not the variable type. Achieved via method overriding and virtual functions. The classic OOP feature that enables dynamic behavior.

Defining multiple methods with the SAME NAME but DIFFERENT PARAMETER LISTS (number or types) in the same class. The compiler picks the right one based on the call.

A child class redefines a method already declared in the parent (with the same signature). At runtime, calls dispatch to the child's version even when accessed through a parent reference.

Overloading = same class, different parameter lists, resolved at compile time (static polymorphism). Overriding = parent/child relationship, same signature, resolved at runtime (dynamic polymorphism).

A method declared in the parent that can be overridden by a child, and is dispatched at runtime through the actual object type. In C++ marked with `virtual`. In Java/C#, methods are virtual by default.

Exposing only the WHAT, hiding the HOW. The user of an object cares about what it does, not how it does it internally. Abstraction reduces cognitive load and lets implementations evolve without breaking callers.

A class that cannot be instantiated directly — only subclassed. It can mix concrete and abstract (unimplemented) methods. Used to define a contract that child classes must complete.

Abstract class can have state (fields), constructors and BOTH abstract and concrete methods. Interface (traditionally) is pure contract — no state, only method signatures. Use abstract class for 'is-a partial parent'; use interface for 'can do X'.

A virtual function with NO implementation in the base class (in C++, declared with `= 0`). Forces every concrete subclass to provide its own implementation. Having even one makes the class abstract.

No — by design. It exists to be inherited from. You can hold a REFERENCE to a concrete child via the abstract type and call its methods polymorphically. But `new AbstractShape()` is a compile error.

All three are 'has-a' relationships, varying in lifecycle dependency. Association = loose (Teacher knows Student). Aggregation = parent has child, child exists independently (Library has Books). Composition = parent owns child, child dies with parent (House has Rooms).

A field or method that belongs to the CLASS, not to any specific instance. Shared across all objects. Accessed via the class name. Useful for constants, counters and utility methods.

In C++, a non-member function (or another class) granted access to a class's private and protected members. Breaks encapsulation by design — use sparingly, only when two classes are tightly bound.

Five design principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion. They make OOP code maintainable, testable and extensible. Coined by Robert C. Martin.

A class should have ONE reason to change. One responsibility, one purpose. A class that handles authentication, persistence AND email sending will be hell to maintain — split it.

Classes should be OPEN for EXTENSION but CLOSED for MODIFICATION. Add new behavior by adding new classes (subclasses, plugins, strategies), not by editing existing code. Reduces regression risk.

Instead of a class creating its dependencies internally, the dependencies are PROVIDED from outside (via constructor, setter or parameter). Makes code testable (swap real with mock) and decoupled.

Coupling = how dependent classes are on each other (LOW is good — loose connections). Cohesion = how focused a class is on its purpose (HIGH is good — does one thing well). Aim for low coupling and high cohesion.