A pricing service has a growing switch for customer type, country, and promotion. How would you decide whether to introduce strategies under the open-closed principle?

Open-closed principle with strategies instead of growing flags

Uses stable extension points for genuinely variable behavior while avoiding speculative abstractions and configuration-driven branching.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would look for one stable axis of behavior that changes independently. If several pricing policies implement the same decision with different rules, a strategy interface can make each policy explicit and let a selector choose one. I would not combine country, customer type, and promotion into arbitrary classes if those dimensions interact; first I would model the actual business rule and its precedence.

Full answer below

Practice focus

Variation axes, strategy selection, stable contracts, composition, feature rules, and the cost of premature abstraction.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
The open-closed principle is about making common extensions local and safe. It does not mean existing code can never be edited or that every conditional needs an interface.
I would look for one stable axis of behavior that changes independently. If several pricing policies implement the same decision with different rules, a strategy interface can make each policy explicit and let a selector choose one. I would not combine country, customer type, and promotion into arbitrary classes if those dimensions interact; first I would model the actual business rule and its precedence.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The calling service should depend on a small contract such as calculating an adjustment from a pricing context. Concrete strategies own their rules, while registration or a factory owns selection. Shared validation and money semantics stay outside duplicated strategy code. A simple switch can remain the clearest design when there are only two stable cases. I introduce the extension point when additions repeatedly modify risky central logic or teams need independently testable policies.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Creating an interface for every conditional.
Encoding several interacting dimensions in class names.
Letting strategy order change the result accidentally.
Using a silent default for unknown policy configuration.

A pricing service has a growing switch for customer type, country, and promotion. How would you decide whether to introduce strategies under the open-closed principle?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement