Strategy in Java

A functional interface is an interface with exactly one abstract method, so a lambda or method reference can implement it. Default and static methods do not count, nor do abstract redeclarations of public Object methods such as equals. Comparator, Runnable, Callable and everything in java.util.function, like Predicate and Function, are functional interfaces. The @FunctionalInterface annotation is optional, but it documents intent and makes the compiler reject a second abstract method that would break every lambda implementing the interface. For strategies this matters: a single-method RoundingPolicy can be supplied as v -> v.setScale(2, RoundingMode.HALF_EVEN), while default methods such as andThen add composition without breaking the functional shape.

A lambda is a concise implementation of a strategy. The Strategy pattern defines a family of interchangeable algorithms behind a common interface and lets the client choose one at run time. If that interface is functional, each concrete strategy can be a lambda or method reference instead of a separate class, so behaviour is passed around as a value. list.sort(Comparator.comparing(Order::placedAt)) is the Strategy pattern in one line: List.sort is the context, Comparator is the strategy interface and the method reference is the concrete strategy. Lambdas can also capture effectively final variables to build parameterised strategies, such as a flat shipping policy that returns a captured amount.

Use an enum when the set of variants is fixed, known at compile time and needs stable names. Enum constants can implement a strategy interface with their own bodies, as VatMode.INVOICE_TOTAL and PER_LINE do, and can be selected by name from configuration or stored in a database column using valueOf and name(). You also get values() for listing options, EnumMap and exhaustive switch support, readable names in logs and singletons for free. Lambdas suit open-ended, local or parameterised strategies created in code. The trade-off is that renaming an enum constant becomes a data migration, and adding a variant means recompiling, so enums do not fit plug-in or tenant-defined strategies.

Predicate<T> takes a value and returns a boolean, so it is a filtering strategy, for example o -> o.status() == Status.OPEN, composable with and, or and negate. Function<T, R> transforms one value into another, so it suits mapping or formatting strategies such as o -> o.id() + " " + o.total(), and composes with andThen and compose. Supplier<T> takes nothing and returns a value, making it a strategy for generating or lazily creating values, such as ID generators or default factories. Consumer<T> accepts a value and returns nothing, so it fits sinks like sending notifications or writing audit entries. UnaryOperator, BinaryOperator and BiFunction cover other shapes, and primitive variants avoid boxing.

Declare your own when the strategy is part of the domain or a public API. A ShippingPolicy with cost(Parcel, Destination) documents intent far better than BiFunction<Parcel, Destination, Money>, whose meaning lives only in a variable name. A named interface can carry Javadoc, default methods for composition, static factories for standard strategies such as RoundingPolicy.bankers(2), and checked exceptions or domain result types if needed. It also appears meaningfully in stack traces, IDE searches and Spring bean types, and two unrelated BiFunctions can no longer be swapped by mistake. Use JDK types for local, technical plumbing inside a method or class, where a new interface would add ceremony without meaning.

Make each strategy a Spring bean implementing a common interface, typically with @Component, and let the container collect them. Injecting List<FraudCheck> gives every implementation, ordered by @Order, while Map<String, FraudCheck> gives them keyed by bean name. The service then builds an immutable registry, often keyed by a name() method rather than bean names so the key is an explicit contract, and selects strategies per request, tenant or configuration. @Qualifier or @Primary pick a single strategy at injection time, and @ConditionalOnProperty enables one through configuration. Validate the registry at startup: if configuration names a strategy with no matching bean, fail the application context instead of the first request.

Lambdas are anonymous, which hurts operations: stack traces show names like lambda$select$3, and logs cannot say which strategy ran unless you add a name or toString. They are harder to test in isolation, because you usually test them through the factory method or class that creates them. They fit poorly when logic grows beyond a few lines, needs several dependencies, or must be configured and referenced by name. Capturing mutable state can create concurrency bugs, and checked exceptions force awkward wrapping. A lambda's identity and equality are also unspecified, so never use lambdas as map keys or compare them with ==. Promote such strategies to named classes or enums.

I would define small, documented functional interfaces for each policy the platform lets consumers change, such as RetryPolicy, TenantResolver or AuditSink, using domain types in the signatures and keeping one abstract method so consumers can plug in a lambda. Each interface ships sensible defaults through static factories, like RetryPolicy.exponential(3), plus default methods for composition. The library accepts implementations through constructors or builders, Spring auto-configuration with @ConditionalOnMissingBean so a consumer's bean overrides the default, and ServiceLoader for non-Spring users. I treat these interfaces as public APIs: semantic versioning, compatibility tests, deprecation before removal, and never adding an abstract method in a minor release, because that breaks every lambda.