OOP and Design Principles: Concepts, SOLID, Design Patterns and Interview Questions

Why OOP is asked in every interview

Object-oriented programming (OOP) is the way most Java, C++, C#, Python and TypeScript code is organised. Interviewers use it to check whether you can model real problems, write code that is easy to change and explain trade-offs. Questions range from definitions ("what is polymorphism?") to design tasks ("design a parking lot"). Weak answers are textbook definitions with no example; strong answers use a short real example and mention why the idea helps (Java, Python, C++).

1. Classes and objects

A class is a blueprint; an object is an instance of it with its own data (state) and behaviour (methods).

class BankAccount {
    private double balance;                 // state
    BankAccount(double opening) { this.balance = opening; }

    void deposit(double amount) {           // behaviour
        if (amount <= 0) throw new IllegalArgumentException("Invalid amount");
        balance += amount;
    }
    double getBalance() { return balance; }
}

Know constructors, this, static vs instance members, and the difference between a class, an object and a reference.

2. The four pillars

Encapsulation: bundle data with the methods that work on it and hide the internals, exposing only a safe interface. Above, balance is private, so nobody can set it to a negative value. Benefit: you can change the internals without breaking users.

Abstraction: expose what something does, hide how. A PaymentMethod interface with pay(amount) hides whether it is a card or UPI. Abstraction is achieved with abstract classes and interfaces. (Encapsulation hides data; abstraction hides complexity. This is a favourite comparison.)

Inheritance: a class reuses and extends another (Savings extends Account), modelling an is-a relationship. Use it carefully: deep hierarchies become fragile.

Polymorphism: the same call behaves differently depending on the object.

Shape[] shapes = { new Circle(2), new Rectangle(3, 4) };
for (Shape s : shapes) {
    System.out.println(s.area());     // each class supplies its own area()
}

• Compile-time: method overloading
• Run-time: method overriding with dynamic dispatch

3. Frequently compared concepts

Topic	Key difference
Overloading vs overriding	Same name, different parameters in one class vs a subclass redefining a parent's method
Abstract class vs interface	Abstract class can hold state and partial implementation; an interface defines a contract and a class can implement many
Composition vs inheritance	Has-a (build from parts) vs is-a (extend); prefer composition for flexibility
Association, aggregation, composition	Uses vs has (parts can exist alone) vs owns (parts die with the owner)
Class vs struct (C++)	Default access is private for class, public for struct
Shallow vs deep copy	Copies references vs copies the nested objects too

Be ready for "why does Java not support multiple inheritance of classes?" (the diamond problem and complexity; interfaces give multiple inheritance of type) and "can you override a static method?" (no, it is hidden, not overridden).

4. Good design: coupling and cohesion

• High cohesion: a class does one focused job
• Low coupling: classes depend on each other as little as possible, usually through interfaces
• DRY (do not repeat yourself), KISS (keep it simple) and YAGNI (do not build what you do not need)
• Program to an interface, not an implementation, and prefer composition over inheritance

5. SOLID principles (with examples)

S: Single Responsibility. A class should have one reason to change. A Report class that fetches data, formats it and emails it has three. Split into ReportData, ReportFormatter and ReportMailer.

O: Open/Closed. Open for extension, closed for modification. Instead of an if/else chain for every new discount type, define a DiscountPolicy interface and add new classes.

interface DiscountPolicy { double apply(double price); }
class FestivalDiscount implements DiscountPolicy {
    public double apply(double price) { return price * 0.9; }
}
class Checkout {
    double total(double price, DiscountPolicy policy) { return policy.apply(price); }
}

L: Liskov Substitution. A subclass must be usable wherever its parent is expected, without surprises. The classic violation: Square extends Rectangle breaks code that sets width and height independently.

I: Interface Segregation. Prefer small, specific interfaces over one large one. A Robot should not be forced to implement eat() because it implements Worker.

D: Dependency Inversion. High-level code should depend on abstractions, not concrete classes. Pass a NotificationSender interface into OrderService instead of creating new EmailSender() inside it. This enables dependency injection and easy testing with fakes.

6. Design patterns that come up most

Patterns are named, reusable solutions to common design problems. Learn the problem each solves, not only the diagram.

Creational

• Singleton: one instance (configuration, logger). Know thread safety and why overuse is a smell.
• Factory (and Abstract Factory): create objects without exposing the creation logic
• Builder: build complex objects step by step (many optional fields)

Structural

• Adapter: make an incompatible interface fit
• Decorator: add behaviour dynamically by wrapping (Java I/O streams)
• Facade: a simple interface over a complex subsystem

Behavioural

• Strategy: swap algorithms at run time (payment, sorting, pricing)
• Observer: notify many listeners when something changes (events, notifications)
• Command, State and Template Method are worth recognising

// Singleton (thread-safe via initialisation-on-demand holder)
class Config {
    private Config() {}
    private static class Holder { static final Config INSTANCE = new Config(); }
    static Config get() { return Holder.INSTANCE; }
}

Most-asked in practice: Singleton, Factory, Builder, Strategy, Observer, Decorator.

7. Low-level design (LLD) questions

Typical prompts: parking lot, library management, ATM, elevator, tic-tac-toe, chess, movie ticket booking, food delivery, a rate limiter or an LRU cache. A reliable approach:

1. Clarify requirements: who uses it, what are the main features, what is out of scope
2. Identify entities (nouns): ParkingLot, Floor, Slot, Vehicle, Ticket, Payment
3. Identify behaviours (verbs): park, unpark, calculate fee, find a free slot
4. Define relationships: a lot has floors; a floor has slots; a ticket links a vehicle and a slot
5. Apply principles and patterns where they help: Strategy for fee calculation, Factory for vehicle types, Singleton for the lot
6. Write the key classes and methods with clear names and handle edge cases (lot full, invalid ticket)
7. Discuss extensions: new vehicle types, concurrency, persistence

Draw a simple class diagram and talk through one flow end to end. Do not build everything; interviewers want clean structure and your reasoning.

8. Frequently asked OOP questions

1. What are the four pillars of OOP? Explain with an example
2. Encapsulation vs abstraction
3. Overloading vs overriding
4. Abstract class vs interface; when would you use each?
5. What is polymorphism? What is dynamic dispatch?
6. Composition vs inheritance
7. What are SOLID principles? Give an example of one
8. What is a constructor? Can it be private? Why?
9. What is the diamond problem?
10. What is the difference between a class and an object?
11. Explain the Singleton pattern and its problems
12. Design a parking lot (or similar)

9. Common mistakes

• Defining terms without a concrete example
• Using inheritance for code reuse when composition would be simpler
• Creating "god classes" that do everything
• Over-engineering a small problem with every pattern you know
• Making all fields public and skipping validation
• Forgetting to discuss testability and extensibility in design answers

10. How to practise

Re-implement three small systems (a library, an ATM and a parking lot) from scratch in your main language. Refactor one of your old projects to apply Single Responsibility and an interface-based design. Explain each pillar aloud using your own project. Then continue with system design basics and core CS subjects.