Strategy vs Conditional Logic

An if/else explosion is conditional logic that keeps growing as new variants of the same concept are added, typically countries, payment methods, customer segments or file formats. The giveaway is not a single long if chain but repetition and growth: the same switch on country appears in shippingCost, eta, carrier and label methods, conditions nest across two axes such as country and express delivery, and every release adds branches in several files, with feature flags accumulating on top. The effects are rising cyclomatic complexity, merge conflicts between teams editing the same methods, an exploding number of test combinations and a high risk that a new branch breaks an existing one.

Strategy turns each variant into its own class or lambda behind a common interface, and a selector chooses the right one once, typically from a map keyed by the variation axis. Adding a variant then means writing a new class and registering it; existing strategies, the selector and their tests stay untouched, which is the Open/Closed Principle in practice. In Spring the registration is automatic: inject List<CountryShipping>, build an unmodifiable map by country, and a new @Component JapanShipping is picked up on the next start. Ownership becomes clearer too, because the team launching a market owns its strategy class and tests without editing anyone else's branches.

Keep the conditional when the variation is small, stable and local. Two or three branches that rarely change, live in one method and are owned by one team are clearer as an if or a switch expression than as an interface plus several classes and a registry. Examples are mapping HTTP status families in an error handler or choosing between a couple of rounding modes. Introducing Strategy there adds files and indirection without reducing risk, which is premature abstraction. Switch to Strategy when the same condition starts appearing in several methods, branches grow every release, variants need runtime selection by configuration, or different teams need to own different variants.

First, pin current behaviour with characterisation tests covering every branch, often a parameterised test with golden inputs and outputs. Second, identify the axis the conditionals switch on, such as country or payment code. Third, extract an interface with one method per decision that switches on that axis. Fourth, move one branch at a time into a strategy class and route only that key through the new path while the others still use the old code, running the tests after each move. Fifth, build a registry keyed by the axis, with an explicit failure for unknown keys. Finally, delete the old conditional once every branch has moved. The system stays releasable throughout.

They give conditionals compile-time safety, so the choice is no longer simply polymorphism good, switch bad. With a sealed interface whose permitted subtypes are records, a pattern-matching switch is exhaustive: no default branch is needed, and adding a new subtype makes the compiler flag every switch that must handle it. Guards with when handle finer conditions such as the card network. This is ideal when the variant set is closed, data-like and owned by the same team as the operations, and new operations arrive more often than new variants. Strategy remains better when variants are open, selected by configuration at runtime, contributed by other teams or plug-ins, or carry their own dependencies.

The expression problem says no single structure makes it cheap to add both new variants and new operations. With switches over a sealed type, operations are functions outside the types, so adding an operation such as refundPolicy is one new function, but adding a variant forces an edit to every switch. With Strategy or polymorphism, each variant is a class implementing all operations, so adding a variant is one new class, but adding an operation means changing the interface and every implementation. The practical rule is to look at change history and predict which axis will grow: choose Strategy when variants multiply, and sealed types with switches when operations do.

I combine complexity with change frequency, because a complex switch that never changes is not worth touching. SonarQube or PMD give cyclomatic and cognitive complexity per method, and Git history shows how often each file changes; the intersection, complex methods modified every few weeks, is the hotspot list. Then I look for repeated switches on the same axis using IntelliJ structural search or simple searches for switches on country or method codes, and for change coupling, where several files with parallel switches are always committed together. Merge-conflict frequency and accumulating boolean flags are further signals. The result is a short list ranked by expected payoff, not a big-bang refactoring plan.

It moves the code structure closer to team ownership, which is Conway's law working in your favour. While country or tenant rules live in shared switch statements, every team edits the same methods, so changes need cross-team review, merge conflicts are common and releases need coordination. Once each market, product line or tenant has its own strategy class, or even its own module contributing strategies through a shared interface, the owning team can change, test and deploy its rules without touching anyone else's. The shared interface becomes a contract that needs governance and careful evolution. The architectural gain is lower coordination cost and faster routine changes, more than reduced code complexity.