Strategy Pattern

Strategy is a behavioural pattern that defines a family of interchangeable algorithms, puts each behind a common interface, and lets the code that uses them choose one at run time without depending on its details. For example, a checkout service might calculate shipping costs with a StandardShipping, ExpressShipping or FreeShipping strategy, all implementing a ShippingCostStrategy interface. The context calls the interface and does not care which strategy it holds. New algorithms can be added without changing existing code, and each one can be tested on its own. In modern Java, simple strategies are often just lambdas.

Strategy has three main roles. The strategy interface declares the operation that all algorithms provide, such as calculate(order). Concrete strategies implement that interface, each with a different algorithm, such as standard, express or free shipping. The context is the class that uses a strategy to do part of its work, such as the checkout service, and holds a reference to the strategy interface rather than any concrete class. In practice there is usually a fourth part: a client, selector or registry that decides which strategy the context should use, for example based on the customer's delivery option or a configuration value.

Selection should happen in one clearly owned place, such as a registry, a factory or a configuration component. A common Spring approach is to inject all strategy beans into a map keyed by name, and have a selector choose by delivery option, tenant or feature flag. Keeping selection in one place means the rules for choosing are easy to find, test and change, and the context stays free of conditional logic. If selection logic is scattered, with if statements in the context and its callers, adding a strategy means hunting through the code and the pattern loses most of its benefit.

Records make good strategy parameters and simple strategies. A strategy's configuration, such as a discount percentage and a cap, can be a record that validates itself in its compact constructor, so an invalid strategy cannot be created. Sealed interfaces close the family of strategies: the interface lists exactly which implementations are permitted, so the compiler can check that a switch over them is exhaustive, and no other team can quietly add an implementation. Together they turn a strategy family into a precise, compiler-checked model, which is well suited to business policies owned by one team, such as pricing or eligibility rules.

Treat the new algorithm as a new strategy rather than changing the old one in place. Implement and test it alongside the existing strategy, then select it through a feature flag for a small share of traffic, for example 5% of customers or one region. Tag metrics and logs with the strategy name, so you can compare business and technical results, such as conversion rate, error rate and latency, between old and new. Increase the share gradually if the results are good. Keep the old strategy available, so rollback is a configuration change rather than a deployment, and remove it once the new one is fully proven.

Make a strategy family open when other teams need to extend it without changing your code, such as a platform extension point for payment providers, notification channels or export formats. An open family needs a stable, documented interface, versioning and validation of third-party implementations. Make it sealed when the family represents business policies owned and reviewed by one team, such as pricing rules or risk scores. Sealing means every variant is known, the compiler checks exhaustive handling, and new variants require a deliberate change by the owning team. Choose deliberately, because changing a widely used open interface later is expensive.

Model each pricing policy as a strategy implementing a common interface, with its parameters held in validated records, so tenants choose policies and settings rather than writing code. Store each tenant's policy configuration in a versioned, audited store, so changes are traceable and can be rolled back. At load time, build a registry that maps tenants to configured strategies, falling back to a default policy when a tenant has none. Validate configurations before they go live, and expose metrics per policy and tenant, such as average price and error rates. For truly custom needs, offer a controlled extension mechanism rather than ad hoc code changes.