Guidelines for Using Design
Patterns
1. Understand the Problem First
“Don’t reach for a pattern unless you know the pain you're
solving.”
Start with identifying the code smells: duplication, tight coupling, rigid
structure.
Ask: “What’s changing frequently here?” That’s where a pattern can help
abstract.
2. Don’t Force Patterns
Premature optimisation and over-engineering are more
dangerous than no patterns at all.
Patterns should emerge naturally as your codebase evolves.
Use them to simplify, not complicate.
3. Learn to Recognise Anti-Patterns
“Singleton isn’t a hammer. Don’t use it to squash every bug.”
Singleton misuse, bloated Factory chains, or unnecessary Observer overkill
can harm readability.
Always question whether a simpler abstraction or basic OOP principle can
solve it.
4. Use Patterns in Interviews Wisely
Guidelines for Using Design Patterns 1
“Explain the intent, not just the name.”
Use patterns to clarify your architecture during system design questions.
Examples:
Strategy when switching algorithms at runtime.
Factory to decouple object creation.
Observer for event-driven flows (e.g., notification systems).
Show you understand both benefits and trade-offs.
5. In Real Projects: Follow the “Pattern When…” Checklist
Pattern Use When...
Strategy You need to switch between multiple algorithms or behaviors
Observer You have many objects depending on a shared state (pub-sub)
Decorator You want to add features dynamically without subclassing
Builder You want to construct complex objects step-by-step
Factory
You want the instantiation logic to be in subclasses
Method
Adapter You’re integrating with legacy or incompatible code
Command You need to encapsulate user actions (Undo/Redo, queues)
State An object changes its behavior based on internal state
Proxy You need to control access or defer expensive operations
Template
You have a base algorithm with variations in steps
Method
6. Patterns Should Improve Maintainability
“If it doesn’t make your code easier to extend, don’t use it.”
Focus on patterns that:
Enable Open-Closed Principle
Guidelines for Using Design Patterns 2
Reduce tight coupling
Promote cleaner testable code
7. Don’t Just Study – Implement!
“Understanding comes through code, not flashcards.”
Try building:
A simple game (Builder, Strategy, State)
A GUI or form builder (Factory, Composite, Observer)
A task manager app (Command, Memento, Mediator)
8. Explain Patterns With Diagrams in Interviews
UML-style sketches can say more than buzzwords.
Use class diagrams, interaction flow, or even pseudo-code.
Show how a pattern helps scale or simplify a module.
9. Mix & Match When Necessary
Many real-world systems use multiple patterns together.
E.g., MVC in web apps:
Controller uses Strategy
View uses Observer
Model uses Factory or Builder
10. Refactor Toward Patterns Over Time
“Don’t start with the pattern; grow into it.”
Guidelines for Using Design Patterns 3
Use regular refactoring to:
Extract strategies
Decouple interfaces
Introduce factories when constructors get bloated
Guidelines for Using Design Patterns 4