52 OOP Interview Questions & Answers

OOP is a programming paradigm that models software around objects — bundles of state (data) and behavior (methods) — rather than a sequence of procedures operating on separate data. It's built on four pillars: encapsulation, inheritance, polymorphism, and abstraction, each addressing a different way of managing complexity as a codebase grows.

public class BankAccount
{
    private decimal _balance;   // hidden — no direct outside access

    public decimal Balance => _balance;

    public void Deposit(decimal amount)
    {
        if (amount <= 0) throw new ArgumentException("Must be positive");
        _balance += amount;
    }
}

Encapsulation bundles an object's data with the methods that operate on it, and hides that data behind a controlled interface — _balance can't be set to a negative number from outside because there's no way to touch it except through Deposit(), which enforces the invariant. This is what keeps an object's internal state always valid, instead of trusting every caller everywhere to maintain it correctly themselves.

public class Shape { public virtual double Area() => 0; }
public class Circle : Shape
{
    public double Radius;
    public override double Area() => Math.PI * Radius * Radius;   // overriding
}

public class Calculator
{
    public int Add(int a, int b) => a + b;
    public double Add(double a, double b) => a + b;   // overloading
}

Polymorphism means the same method call behaves differently depending on the actual object it's invoked on ("many forms") — calling shape.Area() through a Shape reference runs Circle's implementation if that's the real underlying object, resolved at runtime. Overloading is a different, compile-time mechanism entirely — picking which of several same-named methods to call based on argument types.

Inheritance lets a class (the subclass) acquire the members of another class (the base class), modeling an "is-a" relationship — a Dog is an Animal. C# and Java deliberately don't allow multiple inheritance of classes (only of interfaces) specifically to avoid the diamond problem covered later.

Abstraction hides implementation complexity behind a simpler interface, exposing only what a consumer actually needs to know. Techniques: abstract classes (partial implementation plus abstract members to be filled in), interfaces (a pure contract with no implementation), and encapsulation itself (hiding internal state behind methods) all serve abstraction in different ways.

A class is a blueprint — it defines the fields (state) and methods (behavior) that every object created from it will have, but a class itself holds no actual data until it's instantiated.

var fido = new Dog { Name = "Fido" };   // fido is an object — a concrete instance of the Dog class

An object is a concrete instance of a class — it has its own actual state (its own values for the class's fields) in memory, distinct from every other instance of the same class.

Access specifiers control which other code can see/use a given member — the enforcement mechanism that actually makes encapsulation possible, rather than encapsulation being just a naming convention developers have to remember to respect.

public void Print(int value) { ... }
public void Print(string value) { ... }          // different parameter type
public void Print(int value, bool bold) { ... }  // different parameter count
public void Print(double value) { ... }          // different parameter type again

Overloads must differ by parameter count and/or parameter types (or order) — return type alone isn't enough to distinguish two overloads, since the compiler resolves which overload to call based on the arguments at the call site, not the expected return value.