Design Patterns & SOLID Principles

Question 1

What does the S in SOLID stand for, and what problem does it prevent?

Accepted Answer

Single Responsibility — prevents a class from having more than one reason to change — Single Responsibility means each class should have exactly one job — one reason to change. When a class mixes, say, invoice calculation and email sending, a change to the email format forces you to touch the same class that handles billing logic, risking unintended side-effects.

Question 2

The Open/Closed Principle says software entities should be:

Accepted Answer

Open for extension and closed for modification — OCP means you should be able to add new behaviour (extension) without editing existing, tested code (modification). Polymorphism and interfaces make this possible: adding a new shape class does not require touching the area-calculation logic that already works.

Question 3

Which code snippet violates the Liskov Substitution Principle?

Accepted Answer

A Square class that overrides setWidth to keep sides equal, so callers setting width=5 then height=3 get area=9 instead of 15 — LSP says a subtype must be fully substitutable for its base type without surprising callers. The classic Square/Rectangle example breaks this: if you set width=5, height=3 on what you think is a Rectangle, but it is actually a Square (which forces width==height), area() returns 9 instead of 15. The contract of Rectangle is violated.

Question 4

The Interface Segregation Principle (I in SOLID) advises you to:

Accepted Answer

Split large interfaces into smaller ones so clients only depend on what they use — A "fat" interface forces every implementer to provide methods they do not need — like a Robot forced to implement eat() and sleep(). ISP says split it into small focused interfaces (Workable, Eatable, Sleepable) so each class only implements what it actually does.

Question 5

Dependency Inversion (D) says high-level modules should:

Accepted Answer

Depend on abstractions (interfaces) rather than on concrete implementations — DIP keeps high-level business logic decoupled from low-level details like "which database are we using." An OrderService should accept a Database interface, not hard-code new MySQLDatabase(). This lets you swap, mock, or extend the database layer without touching the business logic.

Question 6

The Strategy pattern primarily solves which problem?

Accepted Answer

Allowing algorithms or behaviours to be swapped at runtime without changing the code that uses them — Strategy encapsulates interchangeable algorithms behind a common interface. A sorting module can hold a SortStrategy; swapping QuickSort for MergeSort is just changing which object is injected. This avoids large if/else chains and is a direct application of Open/Closed.

Question 7

Which problem is the Observer pattern designed to solve?

Accepted Answer

Letting many objects react to a change in another object without tight coupling between them — Observer implements a publish-subscribe relationship: a subject holds a list of observers and notifies them when it changes. UI frameworks, event emitters, and reactive streams are all built on this idea. The key benefit is that the subject does not need to know who is listening.

Question 8

What is the main purpose of the Factory pattern?

Accepted Answer

To delegate the responsibility of creating objects to a centralised method or class — Factory centralises object construction so callers are not tied to specific concrete classes. If construction logic changes — say, you now need to inject a dependency into every Logger — you change the factory in one place rather than hunting down every `new Logger()` call site.

Question 9

Why is the Singleton pattern considered risky or overused in modern software?

Accepted Answer

It introduces hidden global state that makes the code hard to test in isolation and difficult to parallelise — A Singleton is global mutable state under a class name. Tests cannot easily swap it out, and two threads may race on its shared state. Modern code often replaces Singletons with dependency-injected objects that happen to be instantiated once by the composition root — giving the same "one instance" guarantee without the hidden coupling.

Question 10

How does the Decorator pattern differ from inheritance when adding behaviour to an object?

Accepted Answer

Decorator wraps an existing object at runtime; inheritance bakes new behaviour into a subclass at compile time — Inheritance bakes new behaviour into a subclass that exists at compile time. Decorator wraps any object that satisfies an interface at runtime, so you can stack behaviours (CachingService(LoggingService(RealService))) without a combinatorial explosion of subclasses. It is composition over inheritance made concrete.

Design Patterns & SOLID Principles

Name the principle

Test your knowledge

What does the S in SOLID stand for, and what problem does it prevent?

The short version

Interview Questions

References & Further Reading

Related topics

Love this visualization?