How to Recognize Which Design Pattern to Apply
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
I start by identifying what type of problem I'm facing — is it about object creation, object structure, or object behavior?
That narrows it down to one of the three pattern categories. Then I look for specific signals in the code. If I see a constructor with tons of parameters and some are optional, that's a Builder signal.
If I'm writing if-else blocks that switch between different algorithms based on some condition, that's Strategy. If two classes have incompatible interfaces but need to work together, that's Adapter. Let's say I'm working on a cart service and I see code like 'if premium customer, calculate this way, else calculate that way' repeated in multiple places — that's a clear Strategy pattern signal because I have a family of interchangeable algorithms.
The key is recognizing the problem before you think about the solution.
A common mistake freshers make is trying to memorize pattern definitions and then looking for places to use them. Instead, you should feel the pain first — messy code, duplication, rigid structure — and then search for the pattern that addresses that specific pain.
In interviews, I'd say something like: 'I noticed repeated object creation logic with subtle variations, which pointed me to Factory' — that shows I'm reasoning from problem to pattern, not just reciting definitions.
How to Recognize Which Design Pattern to Apply
Direct Answer
Look at the core problem: if you're struggling with object creation flexibility, it's Creational; if objects don't fit together or you need to add behavior, it's Structural; if logic varies or objects need to communicate differently, it's Behavioral. Then match specific signals like 'complex construction' (Builder) or 'algorithm family' (Strategy).
Code Example
// Signal: an if-else switching on a TYPE to pick behavior -> Strategy
double discountSmell(String customerType, double price) {
if (customerType.equals("PREMIUM")) return price * 0.85; // behavior varies by type
else return price * 0.95; // <- the Strategy signal
}
// Refactored once the signal is recognized:
interface DiscountStrategy { double apply(double price); }
class PremiumDiscount implements DiscountStrategy { public double apply(double p){ return p * 0.85; } }
class StandardDiscount implements DiscountStrategy { public double apply(double p){ return p * 0.95; } }
// Now a new customer type = a new class, with no edits to existing logic.
Common Mistakes & Pitfalls
- Pattern-First Thinking: Freshers often start by thinking 'which pattern do I know?' instead of 'what's the actual problem here?' This leads to force-fitting patterns where they don't belong.
- Ignoring Scale: Applying Factory when you have one implementation that will never change, or using Strategy for a simple if-else that appears once. The problem signal must be real and recurring.
- Missing the Trigger: Saying 'I'd use Observer' without explaining that the trigger was 'multiple services need to react when cart state changes' — you must articulate the specific pain point that led you to the pattern.
Check your understanding
Answer these without looking back at the article.
- How do you decide between Factory and Abstract Factory?
- What signals indicate Template Method vs Strategy?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.