Design Patterns - lesson 1 | HackIndia Skills

Design Patterns - lesson 1 | HackIndia Skills | HackIndia

Example

A real smell

This is not bad code because it works. It is a candidate because every new provider changes the same function.

Do not jump to a solution yet. Write down the pain first.

function pay(provider, amount) {
  if (provider === "upi") {
    return sendUpiCollect(amount);
  }
  if (provider === "card") {
    return chargeCard(amount);
  }
  if (provider === "wallet") {
    return debitWallet(amount);
  }
  throw new Error("Unknown provider");
}

// Pain: adding netbanking means editing this function again.
// Candidate: behavior changes by provider.

Tip

Use AI carefully

You can ask an AI tool to review one file for design smells. Paste the file and ask for repeated branching, repeated setup, and tight coupling only.

Check the answer yourself. Reject suggestions that require big rewrites, paid services, or patterns that solve problems your app does not have.

Prompt:
Review this file for pattern-shaped refactor candidates.
Only list:
1. Repeated branching
2. Repeated object setup
3. Tight coupling to external services
For each item, quote the exact lines and explain the change pain.
Do not suggest a pattern name yet.

Example

Candidate note

Start a small note in your repo. It becomes proof that you made design choices, not random rewrites.

Keep each note short. One problem, one reason, one possible direction.

refactor-notes.md

Candidate 1: Payment provider branching
File: src/payments/pay.js
Pain: Adding a new provider means editing pay() and retesting all providers.
Signal: Same if-else block chooses behavior by provider.
Possible direction: Move provider-specific behavior out of this function.
Decision later: Choose a pattern only after checking the rest of the app.

Spot pattern-shaped problems

The core move

What to look for

Scan your code

A real smell

Name chasing

Use AI carefully

Candidate note

Do this now

Quick check