Why do lambdas and functional interfaces make passing a strategy lightweight in Java, compared with the classic Strategy implementation?

## Recap: the Strategy pattern Strategy = define a family of interchangeable algorithms behind a common interface and choose one at runtime. The cost of the *classic* form (pre-Java-8) was boilerplate. ## The classic, heavyweight form To vary sort order the old way you wrote a named class implementing the strategy interface: ```java class ByAge implements Comparator<Person> { public int compare(Person a, Person b) { return Integer.compare(a.age(), b.age()); } } // ... list.sort(new ByAge()); ``` Each new ordering = a new top-level or inner class, or at best a verbose **anonymous class**: ```java list.sort(new Comparator<Person>() { public int compare(Person a, Person b) { return Integer.compare(a.age(), b.age()); } }); ``` That's ~5 lines of ceremony to express one line of logic. Strategy worked, but felt expensive, so people under-used it. ## What a functional interface is A **functional interface** is an interface with exactly **one abstract method** (sometimes called a SAM type — Single Abstract Method). It may carry `default`/`static` methods too; only the count of *abstract* methods must be one. The optional `@FunctionalInterface` annotation makes the compiler enforce this. Examples in the JDK: `Comparator<T>` (compare), `Runnable` (run), `Function<T,R>` (apply), `Predicate<T>` (test), `Supplier<T>` (get). Because there is only one method to fill in, the compiler can accept a **lambda expression** or **method reference** wherever a functional interface is expected, and generate the implementing instance for you. ## Lambdas: the lightweight form A **lambda** is an anonymous function literal: `(parameters) -> body`. When the target type is a functional interface, the lambda *becomes* an instance of it: ```java Comparator<Person> byAge = (a, b) -> Integer.compare(a.age(), b.age()); list.sort(byAge); list.sort((a, b) -> Integer.compare(a.age(), b.age())); // inline, no variable ``` A **method reference** (`ClassName::method`) is shorthand for a lambda that just calls one method: ```java list.sort(Comparator.comparingInt(Person::age)); ``` The whole strategy is now a single expression — no class, no fields, no constructor. ## Why this matters for Strategy specifically 1. **Cost collapses.** Passing a strategy is now as cheap as passing any other argument, so you reach for it freely instead of avoiding the boilerplate. 2. **Strategies become anonymous and local.** Many orderings are one-off; you no longer pollute the codebase with a `ByAge`, `ByNameDesc`, etc., class for each. 3. **Composition via combinators.** `Comparator` ships static/default methods that build *new* strategies from existing ones — the fluent way to express composite ordering: ```java Comparator<Person> byNameThenAge = Comparator.comparing(Person::name) .thenComparing(Person::age) .reversed(); ``` `comparing`, `comparingInt`, `thenComparing`, and `reversed` each return a Comparator, so you assemble complex strategies declaratively — far cleaner than hand-writing a multi-key compare. ## Performance/semantics note Lambdas compile to `invokedynamic` and are typically realized without creating a new class file per lambda; a non-capturing lambda (like a stateless comparator) is generally instantiated once and reused. So 'lightweight' is true at the source level *and* avoids the per-strategy class-file proliferation of the anonymous-class era. Capturing lambdas (closing over local variables) may allocate per use, but for typical comparators this is negligible. ## Bottom line Functional interface + lambda turns Strategy from 'a pattern you scaffold' into 'pass a function'. Comparator is the showcase: one abstract method, rich combinators, and direct lambda support make swapping ordering strategies a one-liner.