Strategy Pattern.

Hook: Interviewers love this one because it shows whether you can replace messy if-else logic with clean, swappable behavior.

Question: What is the Strategy Pattern?

Answer: The Strategy Pattern is a design pattern that lets you define a family of algorithms, put each one behind the same interface, and switch between them without changing the code that uses them. In Java, that usually means a Context class holds a reference to a Strategy interface and delegates work to the chosen implementation. It is useful when the behavior changes often, but the main workflow stays the same.

Interview-Ready Answer: I use the Strategy Pattern when I want one piece of code to support multiple interchangeable behaviors, like different discount rules or payment methods. Instead of hardcoding if-else branches, I define a common interface, implement each algorithm separately, and let a context object delegate to the selected strategy. That keeps the code open for extension but closed for modification, and it makes testing each algorithm much easier.

What it is

Detailed Explanation: A strategy is simply one way to do a task. The pattern says: “Put each way in its own class, give them the same contract, and choose one at runtime.” A contract is just an interface, which is a promise that the classes will provide the same method names and inputs.

How it works under the hood

1. The client code creates or receives a strategy implementation, such as RegularDiscount or BlackFridayDiscount.
2. The client passes that strategy into a Context object, often through the constructor or a setter.
3. The Context stores the strategy behind the interface type, not the concrete class.
4. When the business action happens, the Context calls the strategy method, for example calculate() or pay().
5. The chosen implementation runs, so the behavior changes without changing the Context code.

The call is usually one extra interface dispatch, so the runtime cost is tiny: effectively O(1) per call, with one more object reference to store. The real cost is design cost: more classes and more indirection.

When to use it

• When you have many if-else or switch branches for one behavior.
• When algorithms change independently from the rest of the system.
• When you want to test each algorithm in isolation.
• When you want to choose behavior at runtime, not compile time.

Why interviewers like it

It shows you understand the Open/Closed Principle: software should be open for extension, but closed for modification. In plain words, you can add a new strategy without rewriting old code. It also shows you can separate policy from mechanism: the policy is the business rule, and the mechanism is the fixed flow that uses it.

Comparison with similar patterns

Strategy vs State: Strategy is usually chosen by the client and can be swapped for business reasons; State is usually changed internally by the object as it moves through a lifecycle. Strategy vs Template Method: Strategy uses composition and interfaces; Template Method uses inheritance and overrides.

Important edge cases

• Null strategy: if no strategy is set, the context should fail fast or fall back to a default strategy.
• Too many tiny classes: if every rule gets its own class, the code can feel fragmented; sometimes a lambda or enum is enough in Java 8+.
• Stateful strategies: possible, but risky. If the strategy keeps mutable data and is shared across threads, you can get race conditions.
• Overkill: for two stable branches, a simple if-else may be clearer.

Memory hook: Think of a restaurant menu: the kitchen stays the same, but you choose a different recipe card for each order.

Real-World Story: Imagine a checkout service in an e-commerce app. During normal days it applies a 5% discount, during a holiday sale it applies 20%, and for VIP users it may apply a custom rule. The checkout flow should not care which discount formula is used; it should only ask the chosen strategy for the final price.

What goes wrong when teams skip Strategy? They build a giant pricing method with nested if checks for region, user type, campaign, coupon type, and feature flags. Eventually a small change to one discount accidentally breaks another one, because all rules live in the same method and the same release.

Incident example: a Black Friday discount was added directly inside the checkout method, and the developer forgot that subscription renewals should not use it. Users saw wrong totals in the UI, logs showed conflicting discount messages like Applied seasonal discount and Applied renewal discount, and support tickets spiked because customers were charged less than expected or blocked by validation mismatches between frontend and backend totals.

The fix was to move each pricing rule into its own strategy and let the checkout service pick one based on the order type. After that, QA could test each rule independently, and a new promotion could be added without touching the existing ones.

Follow-up & Tricky Questions:

• How is Strategy different from State? Strategy is chosen from the outside to vary an algorithm; State is usually changed by the object itself as its internal status changes. In State, the object often looks like it is “becoming” a different mode over time.
• Can a strategy be a lambda in Java? Yes, if the strategy interface has exactly one abstract method, it is a functional interface, so a lambda can replace a small class. That is a very common Java 8+ style for simple strategies.
• Should strategies be stateless? Usually yes, because stateless strategies are easier to reuse and safer in concurrent code. If they must hold data, keep them immutable whenever possible.
• How do you choose the strategy at runtime? The client, dependency injection container, configuration, request type, or user input can select it. The key idea is that the context should not know the business rules, only how to call them.
• Why not just use inheritance? Inheritance binds behavior at class design time, while Strategy uses composition, which means you can swap behavior without changing the class hierarchy. Composition is usually more flexible and less fragile.
• Is Strategy the same as Template Method? No. Template Method fixes the algorithm skeleton in a base class and lets subclasses override steps; Strategy puts the whole algorithm behind an interface and swaps the whole object.
• Is Strategy always better than if-else? No. If the logic is tiny and stable, branching may be simpler and more readable. Strategy pays off when variation is real, likely to grow, or needs to be tested independently.
• Does Strategy add overhead? Slightly: one extra object and one interface call. In most business apps that cost is negligible, while the maintenance benefit is large.
• Gotcha: Can the context modify strategy data? It should not reach into the strategy’s internals. The whole point is to depend on the interface, not on concrete details.
• Gotcha: What if a strategy throws an exception? The context should either let it bubble up or convert it into a meaningful business error. Silent failure is dangerous because it hides broken rules.

Common Mistakes:

• Turning every small branch into a strategy. Correction: use Strategy only when behavior variation is meaningful; do not over-engineer simple code.
• Putting business logic back into the context. Correction: keep the context thin and delegate the real algorithm to the strategy.
• Using mutable shared strategies in multi-threaded code. Correction: prefer immutable or stateless implementations, or create a new instance per request.
• Forgetting a safe default or null handling. Correction: either fail fast with a clear exception or use a sensible default like NoDiscount.

Memory Hook: “Same kitchen, different recipe card.” The workflow stays fixed; only the recipe changes.

Cheat Sheet:

• Strategy = interchangeable algorithms behind one interface.
• Context delegates; strategy owns the business rule.
• Best for runtime choice and growing rule sets.
• Use composition, not inheritance.
• Prefer stateless implementations when possible.
• Compare with State, Template Method, and simple branching before choosing it.

Practice Tasks:

• Replace a 4-branch if-else price calculator with Strategy.
• Add one lambda-based strategy for a “student discount” rule.
• Write a unit test for each strategy and one test for the context’s null/default behavior.