Design Patterns & SOLID Basics — Interview Questions

How to use this lesson

Freshers aren't expected to recite all 23 Gang of Four patterns. Interviewers want three well-chosen examples, each tied to a real problem, and a clear explanation of SOLID. Your examples matter more than your definitions.

Q1. What is a design pattern, and why do we use them?

Short answer: A design pattern is a proven, reusable solution to a recurring design problem. It's a template for structuring classes and objects, not a piece of code to copy. Patterns give teams a shared vocabulary ("use a strategy here"), and they encode trade-offs that others have already worked out.

Key points to cover:

• The Gang of Four catalogue groups patterns into three families:
  • Creational: how objects are created (Singleton, Factory, Builder, Prototype).
  • Structural: how objects are composed (Adapter, Decorator, Proxy, Facade).
  • Behavioural: how objects interact (Strategy, Observer, Command, Template Method).
• The JDK and Spring use patterns everywhere. For example:
  • InputStream wrappers are Decorators.
  • Runtime.getRuntime() is a Singleton.
  • Spring's @Transactional works through a Proxy.
  • JdbcTemplate uses Template Method.

Learn it in depth → Singleton Pattern

Q2. Name and explain a few common design patterns.

Short answer: Pick patterns you can illustrate:

interface ShippingStrategy { BigDecimal cost(Order o); }
class StandardShipping implements ShippingStrategy { public BigDecimal cost(Order o) { return BigDecimal.valueOf(40); } }
class ExpressShipping  implements ShippingStrategy { public BigDecimal cost(Order o) { return BigDecimal.valueOf(120); } }
// Checkout gets a ShippingStrategy injected: adding "same-day" means a new class, not a new if-branch

Learn it in depth → Strategy Pattern

Q3. How do design patterns affect performance?

Short answer: Usually only slightly. Patterns add some indirection (extra objects, interface calls), and the JIT compiler largely optimises that away. The real gains are maintainability and flexibility. Some patterns directly improve performance: Flyweight shares objects, Proxy enables lazy loading, and Object Pool reuses expensive resources.

Key points to cover:

• Overusing patterns is the real risk: layers of factories and abstractions with only one implementation add complexity without any benefit.
• Measure before optimising. Pattern overhead almost never shows up in a profiler next to I/O and database calls.

Q4. Which pattern would you use to manage database connections efficiently?

Short answer: An Object Pool, meaning a connection pool such as HikariCP (the Spring Boot default). The pool keeps a set of open connections, lends one out for each unit of work, and takes it back afterwards. You avoid the high cost of opening a connection per request, and you cap the load on the database.

Common trap: answering "Singleton, one shared connection". A single JDBC connection can't safely serve concurrent requests: transactions from different threads would interfere, and it becomes a bottleneck. The pool object may be a singleton, but the connections are many.

Key points to cover:

• Size the pool deliberately. Bigger isn't faster, because the database has limited CPU and disk, and too many connections cause contention.
• Always return connections (try-with-resources, or let Spring manage them), or the pool runs dry.

Learn it in depth → Connection Pooling

Q5. How do you choose the right design pattern for a problem?

Short answer: Start from the problem, not the pattern:

1. Identify what varies, or what hurts: object creation, a growing if/else over types, the need to add behaviour, a notification fan-out.
2. Match that to the pattern built for it.
3. Weigh the added complexity against the benefit.
4. Choose the simplest design that meets today's needs, with room for change.

Key points to cover:

• Rules of thumb:
  • A switch on a type → Strategy or polymorphism.
  • Complex object creation → Builder or Factory.
  • "Many things must react to this event" → Observer.
  • "Add logging, caching or retry around calls" → Decorator or Proxy.

Q6. What are the SOLID principles?

Short answer: Five object-oriented design principles that keep code easy to change:

• S — Single Responsibility: a class should have one reason to change. A VehicleRegistration class shouldn't also calculate insurance premiums.
• O — Open/Closed: open for extension, closed for modification. Add a new behaviour by adding a class (a new ServiceType implementation for electric vehicles), not by editing a tested switch.
• L — Liskov Substitution: a subtype must be usable wherever its parent type is expected, without breaking correctness. If ElectricCar can't honour startEngine(), then the abstraction is wrong. Model start() on a Vehicle interface instead of forcing an engine onto every vehicle.
• I — Interface Segregation: don't force clients to depend on methods they don't use. Split a fat VehicleOperations into Drivable, Refuelable, Chargeable and Navigable. An electric car implements Chargeable, not Refuelable.
• D — Dependency Inversion: high-level modules depend on abstractions, not on concrete classes. A VehicleTracker talks to a GpsDevice interface, so any GPS hardware can be plugged in, and a fake one can be used in tests.

// Dependency Inversion + Open/Closed together
interface GpsDevice { Position currentPosition(); }
class VehicleTracker {
    private final GpsDevice gps;                       // abstraction, injected
    VehicleTracker(GpsDevice gps) { this.gps = gps; }
    Position locate() { return gps.currentPosition(); }
}

Key points to cover:

• SOLID is a set of guidelines for managing change, not laws. Applying them mechanically everywhere leads to over-engineering.
• Spring encourages D (dependency injection) and I (small repository and service interfaces) naturally.

Learn it in depth → Single Responsibility & Open/Closed

Follow-up questions this topic invites — and their answers

Q: What's the difference between the Factory Method and Abstract Factory patterns? A: Factory Method creates one product, and lets subclasses (or a single method) decide which concrete class to instantiate. Abstract Factory creates families of related products that must be used together, for example a UI toolkit's Button + Checkbox for Windows versus macOS.

Q: Is Singleton considered an anti-pattern? A: Hand-rolled global singletons often are. They hide dependencies, make unit testing hard, and create global mutable state. Container-managed singletons (Spring beans), injected through constructors, keep the benefit without those problems.

Q: Which SOLID principle does @Autowired constructor injection support? A: Dependency Inversion. Your class declares the abstractions it needs, and the container supplies the concrete implementations.

Q: Give a real-world violation of the Single Responsibility Principle. A: A "god" UserService that validates input, hashes passwords, writes to the database, sends emails and generates reports. Any change to email templates or database schemas forces edits to the same class, and its tests become huge.