Design Patterns

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

In software terms, a design pattern is a language-independent reusable solution/template to commonly occurring problems. It’s not a library/framework, not algorithms, not a copy-paste solution and finally not mandatory (knowing when NOT to use them is equally important)

Creational Patterns

Focus: How objects are created

Creational patterns provide flexibility in what gets created, who creates it, how it’s created, and when. They abstract the instantiation process, making systems independent of how objects are created, composed, and represented.

Pattern	One-Line Summary	Difficulty	Progress
Singleton	Ensure a class has only one instance	⭐	✅
Prototype	Clone objects instead of creating new	⭐	✅
Factory Method	Define an interface for creating objects	⭐⭐	✅
Builder	Construct complex objects step by step	⭐⭐	❌
Abstract Factory	Create families of related objects	⭐⭐⭐	❌

Structural Patterns

Focus: How objects are composed and related

Structural patterns provide flexibility in what gets created, who creates it, how it’s created, and when. They abstract the instantiation process, making systems independent of how objects are created, composed, and represented.

Pattern	One-Line Summary	Difficulty	Progress
Adapter	Convert interface to another interface	⭐	✅
Facade	Provide simplified interface to subsystem	⭐	✅
Decorator	Add behavior to objects dynamically	⭐⭐	✅
Composite	Treat objects and compositions uniformly	⭐⭐	❌
Proxy	Control access to an object	⭐⭐	❌
Bridge	Decouple abstraction from implementation	⭐⭐⭐	❌
Flyweight	Share common state to save memory	⭐⭐⭐	❌

Behavioral Patterns

Focus: How objects communicate and distribute responsibility

Objects need to collaborate to accomplish tasks. Behavioral patterns define clear communication protocols, making interactions flexible and maintainable.

Pattern	One-Line Summary	Difficulty	Progress
Iterator	Access collection elements sequentially	⭐	✅
Template Method	Define skeleton of algorithm in base class	⭐	❌
Chain of Responsibility	Pass requests along a chain of handlers	⭐⭐	❌
Command	Encapsulate requests as objects	⭐⭐	❌
Memento	Save and restore object state	⭐⭐	❌
Observer	Define one-to-many dependency	⭐⭐	🚧
Strategy	Define family of interchangeable algorithms	⭐⭐	❌
Mediator	Reduce coupling between objects	⭐⭐⭐	❌
State	Change behavior when state changes	⭐⭐⭐	❌
Visitor	Add operations without modifying classes	⭐⭐⭐	❌

Why Use Design Patterns?

Benefits

Proven Solutions: Patterns have been tested by many developers over time. You’re not reinventing the wheel.
Common Vocabulary: “Let’s use the Observer pattern” communicates more than explaining pub-sub from scratch.
Better Design: Patterns encourage loose coupling, high cohesion, and maintainable code.
Avoid Pitfalls: Patterns document not just solutions but also consequences and trade-offs.
Learn from Experts: Patterns capture expertise from experienced developers.

Warning Signs of Pattern Abuse

When NOT to use patterns:

Using patterns in simple problems that don’t need them
Forcing a pattern because you recently learned it
Over-engineering for future requirements that may never come
Making code more complex to fit a pattern
Using multiple patterns when one simple solution would work

The goal is clean, maintainable code—not using as many patterns as possible.

Important Notes

Patterns are not rules: They’re guidelines. Break them when it makes sense.
Context matters: A pattern perfect for one problem might be terrible for another.
Keep it simple: No pattern is better than the wrong pattern.
Language differences: Some patterns (like Singleton) have better alternatives in certain languages.
Patterns evolve: Modern languages have features that reduce pattern complexity.
For interview prep, focus on: Singleton, Factory Method, Strategy, Observer, Decorator, and Adapter (most commonly discussed).

On this page