OOP Interview Questions

The four pillars of OOP are:

1. Encapsulation: Bundling data and methods that operate on that data within a single unit (class), and restricting direct access to some components.

2. Abstraction: Hiding complex implementation details and showing only the necessary features of an object.

3. Inheritance: A mechanism where a new class inherits properties and behaviors from an existing class.

4. Polymorphism: The ability of objects to take on many forms. Same method name can behave differently based on the object.

Abstract Class:

• Can have both abstract and concrete methods
• Can have instance variables
• Supports constructors
• A class can extend only one abstract class
• Can have access modifiers (public, private, protected)

Interface:

• All methods are abstract by default (Java 8+ allows default methods)
• Can only have constants (static final variables)
• No constructors
• A class can implement multiple interfaces
• All methods are public by default

When to use:

• Abstract class: When classes share common behavior
• Interface: When you want to define a contract for unrelated classes

Method Overloading (Compile-time Polymorphism):

• Same method name, different parameters
• Happens within the same class
• Return type can be different
• Also called static polymorphism

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

Method Overriding (Runtime Polymorphism):

• Same method name and parameters
• Happens in parent-child relationship
• Return type must be same or covariant
• Also called dynamic polymorphism

class Animal {
    void sound() { System.out.println("Some sound"); }
}
class Dog extends Animal {
    @Override
    void sound() { System.out.println("Bark!"); }
}

SOLID is an acronym for 5 design principles:

S - Single Responsibility Principle A class should have only one reason to change (one job).

O - Open/Closed Principle Classes should be open for extension but closed for modification.

L - Liskov Substitution Principle Derived classes must be substitutable for their base classes.

I - Interface Segregation Principle Many specific interfaces are better than one general interface.

D - Dependency Inversion Principle Depend on abstractions, not concrete implementations.

These principles help create maintainable, scalable, and testable code.

Inheritance (IS-A relationship):

• Child class inherits from parent class
• Tight coupling between classes
• Changes in parent affect child
• Use when there's a true IS-A relationship

class Dog extends Animal { } // Dog IS-A Animal

Composition (HAS-A relationship):

• Class contains objects of other classes
• Loose coupling, more flexible
• Can change behavior at runtime
• Preferred over inheritance

class Car {
    private Engine engine; // Car HAS-A Engine
    private Wheel[] wheels;
}

Rule of thumb: "Favor composition over inheritance" - Gang of Four

Constructor: A special method called when an object is created. Used to initialize object state.

Types:

1. Default Constructor:

class Car {
    Car() { } // No parameters
}

1. Parameterized Constructor:

class Car {
    String brand;
    Car(String brand) {
        this.brand = brand;
    }
}

1. Copy Constructor:

class Car {
    String brand;
    Car(Car other) {
        this.brand = other.brand;
    }
}

Key Points:

• Same name as class
• No return type
• Called automatically on object creation
• Can be overloaded

Java Access Modifiers:

C++ Access Modifiers:

• public: Accessible from anywhere
• private: Only within the class
• protected: Within class and derived classes

class Example {
public:
    int publicVar;
protected:
    int protectedVar;
private:
    int privateVar;
};

Virtual Function (C++): A function declared in base class with virtual keyword that can be overridden in derived class. Enables runtime polymorphism.

class Animal {
public:
    virtual void sound() {
        cout << "Some sound";
    }
};

class Dog : public Animal {
public:
    void sound() override {
        cout << "Bark!";
    }
};

Animal* a = new Dog();
a->sound(); // Output: Bark! (dynamic binding)

Pure Virtual Function: A virtual function with no implementation (= 0). Makes the class abstract.

class Shape {
public:
    virtual double area() = 0; // Pure virtual
};

class Circle : public Shape {
public:
    double area() override {
        return 3.14 * r * r;
    }
};

Key Points:

• Virtual = can be overridden
• Pure virtual = must be overridden
• Class with pure virtual function = abstract class

Diamond Problem: An ambiguity that arises when a class inherits from two classes that have a common base class.

       A
      / \
     B   C
      \ /
       D

Class D inherits from both B and C, which both inherit from A. This creates ambiguity about which version of A's members D should use.

Solutions:

C++ - Virtual Inheritance:

class A { };
class B : virtual public A { };
class C : virtual public A { };
class D : public B, public C { }; // Only one copy of A

Java - No multiple inheritance of classes: Java avoids this by allowing only single class inheritance, but permits multiple interface implementation.

Python - MRO (Method Resolution Order):

class D(B, C):
    pass
# Uses C3 linearization algorithm
print(D.__mro__)

this keyword:

• Refers to the current object
• Used to access current class members
• Can be used to call current class constructor

class Car {
    String brand;
    
    Car(String brand) {
        this.brand = brand; // this.brand = instance variable
    }
    
    void display() {
        System.out.println(this.brand);
    }
}

super keyword:

• Refers to the parent class object
• Used to access parent class members
• Can be used to call parent class constructor

class Vehicle {
    String type = "Vehicle";
    void start() { System.out.println("Vehicle starting"); }
}

class Car extends Vehicle {
    String type = "Car";
    
    void display() {
        System.out.println(super.type); // "Vehicle"
        System.out.println(this.type);  // "Car"
        super.start(); // Calls parent method
    }
}

Shallow Copy:

• Creates a new object but copies references
• Changes to nested objects affect both copies
• Faster, uses less memory

import copy
original = [[1, 2], [3, 4]]
shallow = copy.copy(original)
shallow[0][0] = 99
print(original)  # [[99, 2], [3, 4]] - Changed!

Deep Copy:

• Creates a new object and recursively copies all nested objects
• Completely independent copy
• Slower, uses more memory

import copy
original = [[1, 2], [3, 4]]
deep = copy.deepcopy(original)
deep[0][0] = 99
print(original)  # [[1, 2], [3, 4]] - Unchanged!

Key Point: Deep copy for complete independence, shallow copy for performance.

Singleton: Ensures a class has only one instance and provides global access to it.

Use Cases:

• Database connection pool
• Logger
• Configuration manager
• Thread pool

public class Singleton {
    private static Singleton instance;
    
    private Singleton() {} // Private constructor
    
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Thread-Safe Version:

public class Singleton {
    private static volatile Singleton instance;
    
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

Factory Pattern: Creates objects without specifying exact class. Delegates creation to subclasses.

Benefits:

• Loose coupling
• Easy to extend
• Encapsulates creation logic

// Product interface
interface Shape {
    void draw();
}

// Concrete products
class Circle implements Shape {
    public void draw() { System.out.println("Drawing Circle"); }
}
class Square implements Shape {
    public void draw() { System.out.println("Drawing Square"); }
}

// Factory
class ShapeFactory {
    public Shape createShape(String type) {
        if (type.equals("circle")) return new Circle();
        if (type.equals("square")) return new Square();
        return null;
    }
}

// Usage
ShapeFactory factory = new ShapeFactory();
Shape shape = factory.createShape("circle");
shape.draw();

Static Binding (Early Binding):

• Resolved at compile time
• Used for: static methods, final methods, private methods, overloaded methods
• Faster execution

Dynamic Binding (Late Binding):

• Resolved at runtime
• Used for: overridden methods (virtual methods)
• Enables polymorphism

class Animal {
    static void staticMethod() { System.out.println("Animal static"); }
    void instanceMethod() { System.out.println("Animal instance"); }
}

class Dog extends Animal {
    static void staticMethod() { System.out.println("Dog static"); }
    void instanceMethod() { System.out.println("Dog instance"); }
}

Animal a = new Dog();
a.staticMethod();    // "Animal static" - Static binding
a.instanceMethod();  // "Dog instance" - Dynamic binding

Cohesion: How closely related the responsibilities of a module are.

• High Cohesion = GOOD (single responsibility)
• Low Cohesion = BAD (does too many things)

Coupling: How dependent modules are on each other.

• Low Coupling = GOOD (independent modules)
• High Coupling = BAD (changes cascade)

Goal: High Cohesion + Low Coupling

Example of BAD design:

class UserService {
    void registerUser() { }
    void sendEmail() { }     // Low cohesion
    void generateReport() { } // Not related!
}

Example of GOOD design:

class UserService {
    void registerUser() { }
    void updateUser() { }
    void deleteUser() { }    // High cohesion
}

class EmailService {
    void sendEmail() { }     // Separate concern
}

Observer Pattern: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.

Use Cases:

• Event handling systems
• Newsletter subscriptions
• Stock price updates
• Social media notifications

// Subject interface
interface Subject {
    void attach(Observer o);
    void detach(Observer o);
    void notifyObservers();
}

// Observer interface
interface Observer {
    void update(String message);
}

// Concrete Subject
class NewsChannel implements Subject {
    private List<Observer> observers = new ArrayList<>();
    private String news;
    
    public void attach(Observer o) { observers.add(o); }
    public void detach(Observer o) { observers.remove(o); }
    
    public void notifyObservers() {
        for (Observer o : observers) {
            o.update(news);
        }
    }
    
    public void setNews(String news) {
        this.news = news;
        notifyObservers();
    }
}

// Concrete Observer
class Subscriber implements Observer {
    private String name;
    
    public Subscriber(String name) { this.name = name; }
    
    public void update(String message) {
        System.out.println(name + " received: " + message);
    }
}

// Usage
NewsChannel channel = new NewsChannel();
channel.attach(new Subscriber("Alice"));
channel.attach(new Subscriber("Bob"));
channel.setNews("Breaking News!"); // Both get notified

Key Points:

• Loose coupling between subject and observers
• Supports broadcast communication
• Used in MVC architecture

Strategy Pattern: Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Lets the algorithm vary independently from clients.

Use Cases:

• Payment methods (Credit Card, PayPal, Crypto)
• Sorting algorithms
• Compression algorithms
• Authentication strategies

// Strategy interface
interface PaymentStrategy {
    void pay(int amount);
}

// Concrete strategies
class CreditCardPayment implements PaymentStrategy {
    private String cardNumber;
    
    public CreditCardPayment(String cardNumber) {
        this.cardNumber = cardNumber;
    }
    
    public void pay(int amount) {
        System.out.println("Paid " + amount + " using Credit Card: " + cardNumber);
    }
}

class PayPalPayment implements PaymentStrategy {
    private String email;
    
    public PayPalPayment(String email) {
        this.email = email;
    }
    
    public void pay(int amount) {
        System.out.println("Paid " + amount + " using PayPal: " + email);
    }
}

class UPIPayment implements PaymentStrategy {
    private String upiId;
    
    public UPIPayment(String upiId) {
        this.upiId = upiId;
    }
    
    public void pay(int amount) {
        System.out.println("Paid " + amount + " using UPI: " + upiId);
    }
}

// Context
class ShoppingCart {
    private PaymentStrategy paymentStrategy;
    
    public void setPaymentStrategy(PaymentStrategy strategy) {
        this.paymentStrategy = strategy;
    }
    
    public void checkout(int amount) {
        paymentStrategy.pay(amount);
    }
}

// Usage - can switch strategies at runtime
ShoppingCart cart = new ShoppingCart();
cart.setPaymentStrategy(new UPIPayment("user@upi"));
cart.checkout(500);

cart.setPaymentStrategy(new CreditCardPayment("1234-5678"));
cart.checkout(1000);

Why use Strategy?

• Eliminates conditional statements
• Easy to add new algorithms
• Algorithms can be swapped at runtime

Decorator Pattern: Attaches additional responsibilities to an object dynamically. Provides a flexible alternative to subclassing for extending functionality.

Real-world example: Java I/O Streams

// Without understanding decorator, this looks confusing:
BufferedReader br = new BufferedReader(
    new InputStreamReader(
        new FileInputStream("file.txt")
    )
);

// FileInputStream -> wrapped by InputStreamReader -> wrapped by BufferedReader
// Each wrapper adds functionality!

Custom Example - Coffee Shop:

// Component interface
interface Coffee {
    String getDescription();
    double getCost();
}

// Concrete component
class SimpleCoffee implements Coffee {
    public String getDescription() { return "Simple Coffee"; }
    public double getCost() { return 50; }
}

// Decorator base class
abstract class CoffeeDecorator implements Coffee {
    protected Coffee coffee;
    
    public CoffeeDecorator(Coffee coffee) {
        this.coffee = coffee;
    }
}

// Concrete decorators
class MilkDecorator extends CoffeeDecorator {
    public MilkDecorator(Coffee coffee) { super(coffee); }
    
    public String getDescription() {
        return coffee.getDescription() + " + Milk";
    }
    public double getCost() {
        return coffee.getCost() + 20;
    }
}

class SugarDecorator extends CoffeeDecorator {
    public SugarDecorator(Coffee coffee) { super(coffee); }
    
    public String getDescription() {
        return coffee.getDescription() + " + Sugar";
    }
    public double getCost() {
        return coffee.getCost() + 5;
    }
}

// Usage - stack decorators!
Coffee coffee = new SimpleCoffee();
coffee = new MilkDecorator(coffee);
coffee = new SugarDecorator(coffee);

System.out.println(coffee.getDescription()); // Simple Coffee + Milk + Sugar
System.out.println(coffee.getCost());        // 75

Key Points:

• Open/Closed Principle in action
• Can stack multiple decorators
• More flexible than inheritance

These describe relationships between classes:

Association (Uses-A)

A general relationship where objects are aware of each other.

class Teacher {
    void teach(Student student) {
        // Teacher uses Student
    }
}

Aggregation (Has-A, Weak)

A special form of association. Child can exist independently of parent.

class Department {
    private List<Professor> professors; // Professors can exist without Department
    
    public Department(List<Professor> professors) {
        this.professors = professors;
    }
}

// If Department is deleted, Professors still exist

Composition (Has-A, Strong)

A strong form of aggregation. Child cannot exist without parent.

class House {
    private List<Room> rooms;
    
    public House() {
        // Rooms are created inside House
        this.rooms = new ArrayList<>();
        this.rooms.add(new Room("Bedroom"));
        this.rooms.add(new Room("Kitchen"));
    }
}

// If House is destroyed, Rooms are destroyed too

Comparison Table

Interview Tip: Composition = "part-of", Aggregation = "has-a"

Decision Framework:

Use Abstract Class when:

1. You have shared code/implementation
2. You want to provide default behavior
3. Classes share a common base (IS-A relationship)
4. You need non-public members (protected/private)
5. You need instance variables

abstract class Animal {
    protected String name;  // Shared state
    
    public void sleep() {   // Shared implementation
        System.out.println(name + " is sleeping");
    }
    
    abstract void makeSound();  // Must implement
}

Use Interface when:

1. You want to define a contract/capability
2. Multiple unrelated classes need same capability
3. You need multiple inheritance
4. You're defining behavior, not state

interface Flyable {
    void fly();  // Just the contract
}

// Unrelated classes can implement
class Bird implements Flyable { ... }
class Airplane implements Flyable { ... }
class Superman implements Flyable { ... }

Quick Decision Chart:

Need shared code?
├── YES → Abstract Class
└── NO → Interface

Need multiple inheritance?
├── YES → Interface
└── NO → Either works

Is it "IS-A" or "CAN-DO"?
├── IS-A (Dog IS-A Animal) → Abstract Class
└── CAN-DO (Bird CAN-DO fly) → Interface

Java 8+ Note:

Interfaces can now have:

• default methods (with implementation)
• static methods

This blurs the line, but abstract classes still win for shared state.

Builder Pattern: Separates the construction of a complex object from its representation. Useful when an object has many optional parameters.

Problem it solves:

// Without Builder - Telescoping constructor anti-pattern
User user = new User("John", "Doe", 25, "john@email.com", "123 Street", "NYC", "USA", "10001");
// Which parameter is which? Hard to read!

Solution with Builder:

public class User {
    private String firstName;
    private String lastName;
    private int age;
    private String email;
    private String address;
    
    private User(Builder builder) {
        this.firstName = builder.firstName;
        this.lastName = builder.lastName;
        this.age = builder.age;
        this.email = builder.email;
        this.address = builder.address;
    }
    
    // Static inner Builder class
    public static class Builder {
        private String firstName;  // Required
        private String lastName;   // Required
        private int age;           // Optional
        private String email;      // Optional
        private String address;    // Optional
        
        public Builder(String firstName, String lastName) {
            this.firstName = firstName;
            this.lastName = lastName;
        }
        
        public Builder age(int age) {
            this.age = age;
            return this;
        }
        
        public Builder email(String email) {
            this.email = email;
            return this;
        }
        
        public Builder address(String address) {
            this.address = address;
            return this;
        }
        
        public User build() {
            return new User(this);
        }
    }
}

// Usage - clean and readable!
User user = new User.Builder("John", "Doe")
    .age(25)
    .email("john@email.com")
    .address("NYC")
    .build();

Real-world examples:

• StringBuilder in Java
• HttpRequest.Builder
• AlertDialog.Builder in Android

Benefits:

• Readable code with named parameters
• Immutable objects
• Validation before object creation

Adapter Pattern: Allows incompatible interfaces to work together. Acts as a bridge between two incompatible interfaces.

Real-world analogy: Power adapter that lets US devices work in EU sockets.

Use Cases:

• Legacy code integration
• Third-party library integration
• API compatibility layers

// Existing interface your code expects
interface MediaPlayer {
    void play(String filename);
}

// New interface from a library (incompatible)
interface AdvancedMediaPlayer {
    void playMp4(String filename);
    void playVlc(String filename);
}

// Advanced player implementation
class VlcPlayer implements AdvancedMediaPlayer {
    public void playVlc(String filename) {
        System.out.println("Playing VLC: " + filename);
    }
    public void playMp4(String filename) { }
}

class Mp4Player implements AdvancedMediaPlayer {
    public void playMp4(String filename) {
        System.out.println("Playing MP4: " + filename);
    }
    public void playVlc(String filename) { }
}

// ADAPTER - bridges the gap
class MediaAdapter implements MediaPlayer {
    private AdvancedMediaPlayer advancedPlayer;
    
    public MediaAdapter(String audioType) {
        if (audioType.equals("vlc")) {
            advancedPlayer = new VlcPlayer();
        } else if (audioType.equals("mp4")) {
            advancedPlayer = new Mp4Player();
        }
    }
    
    public void play(String filename) {
        String type = filename.substring(filename.lastIndexOf(".") + 1);
        if (type.equals("vlc")) {
            advancedPlayer.playVlc(filename);
        } else if (type.equals("mp4")) {
            advancedPlayer.playMp4(filename);
        }
    }
}

// Usage - client uses simple interface
class AudioPlayer implements MediaPlayer {
    private MediaAdapter adapter;
    
    public void play(String filename) {
        String type = filename.substring(filename.lastIndexOf(".") + 1);
        
        if (type.equals("mp3")) {
            System.out.println("Playing MP3: " + filename);
        } else if (type.equals("vlc") || type.equals("mp4")) {
            adapter = new MediaAdapter(type);
            adapter.play(filename);
        }
    }
}

AudioPlayer player = new AudioPlayer();
player.play("song.mp3");  // Native
player.play("movie.mp4"); // Through adapter
player.play("video.vlc"); // Through adapter

Key Points:

• Converts one interface to another
• Enables code reuse without modification
• Follows Open/Closed Principle