Strategy Pattern — low level design interview guide

Use Strategy when a class chooses behavior with branches like if (type == CREDIT_CARD) ... else if (type == UPI) ....

The problem starts when one class holds many algorithms. Every new payment method, pricing rule, or allocation rule forces edits to the same class. Old branches need retesting each time.

Strategy moves each algorithm into its own class. The main class depends on an interface and calls the selected algorithm through that interface.

Problem: Type-Based Branching Grows

A common first version of payment code looks like this:

1if (type == CREDIT_CARD) {
2    // validate card
3    // charge card
4} else if (type == UPI) {
5    // validate UPI
6    // debit UPI
7} else if (type == WALLET) {
8    // check wallet balance
9    // debit wallet
10}

Two payment methods may look harmless. The design gets harder to change when the interviewer adds wallets, rewards, net banking, refunds, retries, fraud checks, and country rules.

PaymentProcessor now has too many reasons to change. Every new payment method requires editing the same class. Each edit can break code that already worked.

OCP Problem

Open/Closed Principle means stable code should stay closed for edits when you add new behavior.

In interviews, type-based branching is the smell. Use Strategy when each branch is a different algorithm for the same operation.

Fix: Put Algorithms Behind an Interface

Strategy defines a family of algorithms. Each algorithm gets its own class. The context calls the selected algorithm through an interface.

For payments, the algorithm family is “how to pay.” Credit card, UPI, and wallet are separate strategies. PaymentProcessor only calls pay(amount).

Components

Inject the strategy into the context, usually through the constructor. The caller knows which behavior is needed.

Interview Trigger

Think “Strategy” when you see a branch on a type and each branch runs a different algorithm.

Common triggers:

• Payment methods: CREDIT_CARD, UPI, WALLET, NET_BANKING
• Pricing rules: regular price, surge price, discount price
• Allocation rules: nearest parking spot, cheapest parking spot, largest available spot
• Sorting algorithms: quick sort, merge sort, heap sort
• Routing policies: fastest route, cheapest route, fewest hops

Ask: “Are these branches different ways to perform the same operation?” If yes, Strategy usually fits.

Cases Where Strategy Does Not Fit

Use Strategy only when behavior varies.

A strong interview answer names the boundary: use Strategy where behavior varies independently from the object using it.

Full Example: PaymentProcessor with Strategy Injection

1public class Main {
2    interface PaymentStrategy {
3        void pay(int amount);
4    }
5
6    static class CreditCardPayment implements PaymentStrategy {
7        private final String cardNumber;
8        CreditCardPayment(String cardNumber) { this.cardNumber = cardNumber; }
9
10        @Override
11        public void pay(int amount) {
12            System.out.println("Paid " + amount + " using card " + cardNumber);
13        }
14    }
15
16    static class UpiPayment implements PaymentStrategy {
17        private final String upiId;
18        UpiPayment(String upiId) { this.upiId = upiId; }
19
20        @Override
21        public void pay(int amount) {
22            System.out.println("Paid " + amount + " using UPI " + upiId);
23        }
24    }
25
26    static class PaymentProcessor {
27        private final PaymentStrategy strategy;
28        PaymentProcessor(PaymentStrategy strategy) { this.strategy = strategy; }
29        void process(int amount) { strategy.pay(amount); }
30    }
31
32    public static void main(String[] args) {
33        PaymentProcessor processor = new PaymentProcessor(new UpiPayment("user@upi"));
34        processor.process(500);
35    }
36}

Constructor injection keeps payment execution separate from payment selection. PaymentProcessor receives the strategy and calls it.

Mini Example: Parking Spot Allocation Strategy

Parking lot design is a common LLD interview case. A weak version puts allocation rules inside ParkingLot with branches like if (vehicleType) or if (policy). The class keeps growing when the interviewer asks for nearest-first, cheapest-first, or electric-charging-first allocation.

Move allocation into a strategy. ParkingLot asks an AllocationStrategy to select a spot.

1import java.util.*;
2
3public class Main {
4    interface AllocationStrategy {
5        int allocate(List<Integer> spots);
6    }
7
8    static class NearestSpotStrategy implements AllocationStrategy {
9        @Override
10        public int allocate(List<Integer> spots) {
11            return spots.get(0);
12        }
13    }
14
15    static class FarthestSpotStrategy implements AllocationStrategy {
16        @Override
17        public int allocate(List<Integer> spots) {
18            return spots.get(spots.size() - 1);
19        }
20    }
21
22    static class ParkingLot {
23        private final AllocationStrategy strategy;
24        ParkingLot(AllocationStrategy strategy) { this.strategy = strategy; }
25        int park(List<Integer> availableSpots) { return strategy.allocate(availableSpots); }
26    }
27
28    public static void main(String[] args) {
29        ParkingLot lot = new ParkingLot(new NearestSpotStrategy());
30        System.out.println("Allocated spot " + lot.park(Arrays.asList(1, 2, 3)));
31    }
32}

Allocation strategies are easy to test. You can test NearestSpotStrategy without building the full parking lot system.

Strategy vs State

Strategy and State both use an interface with multiple implementations. The intent separates them.

Strategy is chosen by the client. State changes inside the object as the object moves through its lifecycle.

For payment, the user chooses UPI or credit card. That is Strategy.

For an order moving from PLACED to SHIPPED to DELIVERED, the order changes its own status. That is State.

Use Strategy when the algorithm acts like a plug-in. Use State when behavior changes because the object’s lifecycle changes.

Decision Tree

Use Strategy for interchangeable behavior. Use Factory for object construction. When both problems exist, use Factory to create the Strategy and inject it into the Context.

Default Recommendation

In LLD interviews, use Strategy when you see if/else or switch on a type and each branch is a different algorithm for the same operation.

Steps:

1. Define an interface for the operation.
2. Create one class per algorithm.
3. Inject the strategy into the context through the constructor.
4. Add a Factory if selecting or constructing the right strategy makes the context noisy.

Common Candidate Mistakes

• Creating Strategy for one implementation. The design looks mechanical.
• Keeping the if/else inside the context and only moving code into helper methods. Method size drops, but OCP still fails.
• Instantiating the concrete strategy inside PaymentProcessor. Selection logic becomes hidden, and tests get harder.
• Confusing Strategy with State. Strategy is chosen by the caller. State changes inside the object during lifecycle transitions.
• Creating one large PaymentStrategy with unrelated methods like refund, validateKyc, sendOtp, and calculateReward. Keep the interface focused on the operation the context needs.
• Using Strategy to solve object creation. If construction is complex, combine Strategy with Factory.

Numbers to Know

Strategy is a design pattern for maintainability and testing. It does not make a slow algorithm fast.

In interviews, say the runtime overhead is constant and small. The design benefit is isolated change.