Strategy Pattern & Dependency Inversion

The claim under test

"We use the Strategy pattern here." It is one of the most frequently made and least frequently earned claims in enterprise Java, and unlike most architectural disputes it is decidable in about forty seconds. You do not need to agree on taste. You need to look at two things.

• Test 1: the Context field. Does the class that uses the algorithm declare its dependency as the interface, or does it name a concrete class? A Context that names an implementation is not a Context; it is a caller.
• Test 2: the type test. Is there an instanceof, a getClass(), a switch over a type discriminator, or an if/else chain choosing behaviour inside the Context? If so, the branching is the algorithm selection, and you have conditional dispatch wearing an interface as a hat.

// Test 1 fails: the field names a concrete class.
private final RayCastingCollisionAlgorithm rayCasting;

// Test 1 passes: the field names the abstraction. This class cannot know,
// and has no way to ask, which implementation it was handed.
private final CollisionAlgorithm collisionAlgorithm;

// Test 2 fails: the Context is branching on the runtime type of its input.
if (area instanceof Polygon p) { return rayCasting.contains(p, position); }

// Test 2 passes: one call, dispatched by the JVM rather than by this class.
return collisionAlgorithm.contains(area, position);

Both tests are about where knowledge lives. In a real Strategy, the knowledge of which algorithm applies lives outside the Context: in the caller, in a factory, in configuration, in the wiring. Inside the Context there is one call and no opinion.

GoF Strategy, structurally

Strategy comes from the Gang of Four, or GoF: the four authors of Design Patterns, published in 1994. Their definition is short enough to hold in one hand, and every clause of it is load-bearing.

Note the three obligations packed into one sentence: a family (so, more than one), separate classes (so, not branches in a method), and interchangeable objects (so, a common supertype the user of them can hold). The same page is explicit about the Context's field and about who does the choosing:

Wikipedia states the consequence of that field being typed as the interface, which is the whole reason the pattern is worth the classes it costs:

Dependency Inversion: what "inversion" actually means

Robert Martin's principle is usually quoted in its first half and forgotten in its second. Both halves matter, and it is the second one that makes it a principle rather than a style preference:

Read literally, that is satisfiable by any interface anywhere. It is not. The word being inverted names something specific, and the same article says exactly what:

The abstraction is owned by the consumer. That is the sentence almost every tutorial skips, and without it the Dependency Inversion Principle (DIP) degenerates into "use interfaces". The interface is not a neutral object floating between two modules. It is a statement of what the high-level module requires, written in the high-level module's vocabulary, and it belongs in the high-level module's package. The implementation then reaches upward to satisfy it. Martin Fowler catalogued the mechanic separately:

DI is not DIP, and neither is IoC

Three terms, routinely used as synonyms, describing three different things: dependency injection (DI), the Dependency Inversion Principle (DIP), and inversion of control (IoC). Fowler had to coin one of them precisely because the existing name was too broad:

The row that surprises people is the last one. A hand-written class that takes an interface in its constructor and is instantiated with new obeys DIP completely and uses no container at all. Conversely, and this is the shape of the production defect further down, a class can be a perfectly wired Spring @Service using textbook constructor injection and still violate DIP on every line, because what it is injected with are concrete types.

The "cosmetic DIP" smell

Here is the pattern to learn to see: an interface PaymentService, one implementation PaymentServiceImpl, both in package …payment, the interface existing because a mocking library was easier to satisfy that way. Every DIP box is ticked and nothing has been inverted. The consumer still depends on a type shipped by the implementer; move the implementation and the interface moves with it; add a second implementation and you discover the interface was shaped around the first one's internals.

What this looked like in production

Doing it properly

Three tabs: the defect as it was, the repair that shipped, and the reference implementation from the same service. Read the second and third tabs as the model to copy, and the first as the shape to recognise and avoid. The repair was not "add an interface", because the interface already existed. It was finishing it, then deleting the branch that only existed because it was unfinished.

package geofencing;

import geofencing.algorithm.HaversineDistanceCollisionAlgorithm;
import geofencing.algorithm.RayCastingCollisionAlgorithm;
import org.springframework.stereotype.Service;

/**
 * The abstraction already exists, one package away. This class never names it.
 * Constructor injection is used correctly, so this is textbook DI, and it is
 * not DIP, because every dependency it declares is a concrete type.
 */
@Service
public class GeofencingEvaluationService {

    private final RayCastingCollisionAlgorithm rayCasting;
    private final HaversineDistanceCollisionAlgorithm haversine;

    public GeofencingEvaluationService(RayCastingCollisionAlgorithm rayCasting,
                                       HaversineDistanceCollisionAlgorithm haversine) {
        this.rayCasting = rayCasting;
        this.haversine  = haversine;
    }

    public boolean isInside(Geometry area, Point position) {
        // Conditional dispatch, not Strategy. A third geometry means editing
        // this method, precisely what a Strategy Context never has to do.
        if (area instanceof Polygon polygon) {
            return rayCasting.contains(polygon, position);
        } else if (area instanceof Circle circle) {
            return haversine.contains(circle, position);
        }
        throw new IllegalArgumentException("Unsupported geometry: " + area);
    }
}

package geofencing;

/**
 * DIP: the abstraction lives in the package that CONSUMES it, not the one
 * that implements it. Move this file into geofencing.algorithm and you have
 * indirection again. The arrow points down and nothing has been inverted.
 */
public interface CollisionAlgorithm {

    /** What this algorithm is for. Domain data, not a Spring bean name. */
    GeometryKind supports();

    boolean contains(Geometry area, Point position);
}

// ---------------------------------------------------------------------------

package geofencing.algorithm;

import geofencing.CollisionAlgorithm;   // the low-level package depends UPWARD
import geofencing.GeometryKind;
import org.springframework.stereotype.Component;

@Component
public class HaversineDistanceCollisionAlgorithm implements CollisionAlgorithm {
    // That clause is the entire fix. RayCastingCollisionAlgorithm already had it.

    @Override
    public GeometryKind supports() {
        return GeometryKind.CIRCLE;
    }

    @Override
    public boolean contains(Geometry area, Point position) { … }
}

// ---------------------------------------------------------------------------

package geofencing;

import java.util.List;
import java.util.Map;
import java.util.function.Function;
import java.util.stream.Collectors;
import org.springframework.stereotype.Service;

@Service
public class GeofencingEvaluationService {

    private final Map<GeometryKind, CollisionAlgorithm> byKind;

    /**
     * Spring hands over every bean implementing the interface. The map is
     * built here rather than injected as Map<String, CollisionAlgorithm>,
     * because Spring keys that map by BEAN NAME, a container detail, not a
     * domain fact. Keying on supports() keeps selection inside the domain.
     */
    public GeofencingEvaluationService(List<CollisionAlgorithm> algorithms) {
        this.byKind = algorithms.stream().collect(Collectors.toUnmodifiableMap(
                CollisionAlgorithm::supports, Function.identity()));
    }

    public boolean isInside(Geometry area, Point position) {
        var algorithm = byKind.get(area.kind());
        if (algorithm == null) {
            throw new IllegalStateException("No CollisionAlgorithm for " + area.kind());
        }
        return algorithm.contains(area, position);   // no type test, no branch
    }
}

package spatial.rtree;

import java.util.List;
import java.util.Objects;

/**
 * Node splitting is the one decision an R-Tree genuinely has to make, and the
 * one the literature disagrees about: linear-cost, quadratic-cost and the
 * R*-tree variant are documented members of the same family. The tree owns
 * this interface: a split algorithm is never allowed to own the tree.
 */
public interface SplitStrategy {
    <T> Split<T> split(List<Entry<T>> entries, int minEntries);
}

/** A split is a value, so it is a record, not a service and not a bean. */
public record Split<T>(List<Entry<T>> left, List<Entry<T>> right) {
    public Split {
        left  = List.copyOf(left);
        right = List.copyOf(right);
    }
}

// ---------------------------------------------------------------------------

public final class RTree<T> {

    // The Context holds the INTERFACE. There is no reference to a concrete
    // strategy anywhere in this class: not in a field, not in a branch.
    private final SplitStrategy splitStrategy;
    private final int maxEntries;

    public RTree(SplitStrategy splitStrategy, int maxEntries) {
        this.splitStrategy = Objects.requireNonNull(splitStrategy, "splitStrategy");
        this.maxEntries    = maxEntries;
    }

    /** Selection lives with the caller, and needs no container to do it. */
    public static <T> RTree<T> withDefaults() {
        return new RTree<>(new LinearSplitStrategy(), 8);
    }

    private void overflow(Node<T> node) {
        Split<T> split = splitStrategy.split(node.entries(), maxEntries / 2);
        node.replaceWith(split.left(), split.right());
    }
}

Strategy vs plain conditional dispatch

The honest counterweight to everything above: not every branch wants to be a class. The Strategy pattern's own documentation lists this as its first drawback, and it is the sentence to quote back at anyone converting a two-line if into three files.

Canonical sources

• Refactoring.guru: Strategy · intent, the Context's field, who selects, and the cons quoted above.
• Wikipedia: Strategy pattern · the structural statement that the Context refers to the interface and is thereby independent of the implementation.
• Wikipedia: Dependency inversion principle · both clauses, what is reversed, and the ownership of the abstractions by the higher layers.
• Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern · why "Inversion of Control" was too generic a name, and what DI actually removes.
• Martin Fowler: Separated Interface · the packaging mechanic that makes ownership concrete.