Behavioral Patterns: Strategy and Observer

Strategy encapsulates interchangeable algorithms behind a shared interface, which makes it the runtime sibling of the open-closed idea you met in the SOLID phase: the difference is that strategy selection can be decided per call, per tenant, or per configuration, rather than fixed at compile time. The pricing engine from earlier topics returns as the running example, now with the question the pattern actually answers: where does the choice of algorithm live?

public interface PricingStrategy {
    Money price(Cart cart, PricingContext ctx);
    String code();                        // for config: 'standard'|'vip'|'bogo'
}

public final class VipPricing implements PricingStrategy {
    public Money price(Cart cart, PricingContext ctx) {
        return cart.subtotal().minus(percent(cart.subtotal(), 10));
    }
    public String code() { return "vip"; }
}

public final class PricingEngine {                 // the context
    private final Map<String, PricingStrategy> byCode;
    private final PricingStrategy fallback;

    public Money price(Cart cart, PricingContext ctx) {
        PricingStrategy s = byCode.getOrDefault(ctx.segment(), fallback);
        return s.price(cart, ctx);                  // no conditionals here
    }
}

Notice what the selection map buys beyond the class-per-rule refactor: the choice is data. A configuration row (segment=vip → strategy=vip) selects the algorithm, so pricing experiments become configuration changes with audit trails instead of deployments — the property that makes strategy the natural pattern for anything a business stakeholder will want to vary without an engineer on the keyboard. The context owns everything shared across strategies (currency rules, rounding mode, the audit log of which strategy ran and why), which keeps each strategy a pure expression of its one rule and keeps the unit tests trivially small.

Three design details interviews probe. Strategy versus conditional: the pattern pays when strategies are real (several, stable, independently tested) and when selection has a life of its own; a two-branch if for a binary flag stays an if until the second real variant arrives — the same timing discipline as before. Composition: when two strategies can legitimately apply (VIP discount plus seasonal BOGO), decide composition explicitly in the context (sum, cap, precedence order) rather than letting map lookup pick one; unstated composition rules are how pricing incidents happen. Stateless vs stateful strategies: keep strategies stateless and pass per-call data through the context object; a strategy holding mutable fields becomes a hidden shared singleton in most DI configurations, which is a concurrency incident waiting for traffic. The pattern's classic counterpart fixes the other axis — the template method fixes an algorithm skeleton in an abstract class while subclasses fill in steps, which is where the third chapter takes the comparison. A note on discoverability, which separates production strategy implementations from textbook ones: at runtime, someone will ask which strategy a given cart used and why. Strategies therefore carry a stable code(), the context logs the selection decision alongside the result, and the configuration map has one obvious owner with a documented default. A strategy engine nobody can interrogate becomes an incident investigationblack hole, and the fix costs one log line per decision plus the map in version control. The same interrogability standard applies to the fallback: when a cart carries no segment at all, the engine must resolve to the standard strategy and say so in the audit trail, because silent defaults are how a pricing experiment ends up billing customers at a rate nobody chose.

The order use case has just saved an order. Now four things must happen: the loyalty service adds points, the warehouse reservation system is notified, analytics receives an event, and the confirmation email is queued. The naive version calls them in sequence inside the use case — and with every addition, the use case grows another collaborator, another failure mode, and another reason for the next engineer to hesitate before touching the happy path. Observer decouples publishers from subscribers so listeners evolve independently: the use case announces that something happened; interested parties react without the announcer knowing who they are.

The in-process form is small and sufficient when the listeners are in the same deployment:

public record OrderPlaced(UUID orderId, UUID customerId,
                          Money total, List<Line> lines) {}

public interface OrderPlacedListener {
    void onOrderPlaced(OrderPlaced event);
}

public final class RefundOrder {            // publisher: knows no listeners
    private final List<OrderPlacedListener> listeners;
    public RefundOrder(OrderRepository repo, List<OrderPlacedListener> ls) {
        this.listeners = List.copyOf(ls);   // wired at composition root
    }
    public CheckoutReceipt place(PlaceCheckout cmd) {
        Order order = orders.save(Order.from(cmd));
        var event = new OrderPlaced(order.id(), order.customerId(),
                                    order.total(), order.lines());
        listeners.forEach(l -> l.onOrderPlaced(event));   // notification
        return new CheckoutReceipt(order.id());
    }
}

The use case's collaborator count is now fixed forever; the loyalty team's change ships in the loyalty module; and unit tests subscribe a recording listener instead of mocking four services. But the pattern's power is exactly where its design questions concentrate, and the first question is failure semantics: a synchronous in-process listener that throws will break the publisher's flow unless you catch per listener — and if you do catch, you have silently converted the notification into fire-and-forget with best-effort logging. That is a legitimate choice, but make it explicit: per-listener try/catch with error logging and a metric, or a queue that retries. What must never happen is one flaky listener rolling back a customer's order.

The second question is consistency of delivery model: once listeners cross process boundaries, the same conceptual event wants to be a message on a bus (Kafka, SQS), which changes the guarantees — at-least-once delivery means every listener must be idempotent, and ordering must be argued for per partition key. Many architectures keep both tiers deliberately: an in-process observer for the fast, same-transaction concerns (audit row written with the order), and a bus event for the cross-service concerns (analytics, warehouse), with the outbox pattern bridging them so the event is durably recorded in the same transaction that saved the order. Naming both tiers and their different guarantees is a strong systems answer.

The third question, asked by every reviewer eventually: does the publisher block on slow listeners? The in-process loop is sequential and bounded; the bus decouples in time but adds infrastructure. Choose by the listener's nature — an audit write wants the transaction's fate; an analytics sink wants independence from it — and write the choice into the ADR so the next listener is placed by policy rather than by whoever wires it that week. Wiring deserves a sentence of its own because it is where observer deployments go wrong in review. The listener list must be assembled at the composition root, immutable for the process lifetime, and ordered deliberately when order matters (audit before analytics, say) — an unordered set of listeners whose relative sequence is accidental is a flakiness generator. In frameworks that auto-discover listeners by annotation, the discovery itself becomes configuration, and the composition-root principle says: make the list visible in one place a reviewer can read, rather than scattered across modules that happen to be on the classpath.

Both patterns solve 'the same flow with different steps', and teams pick between them by instinct. The choice is not taste; it follows from where the variation axis sits and whether the varying pieces need to be composed or reused outside the flow.

Template method fixes the skeleton in a base class and lets subclasses override the hooks:

public abstract class ImportJob {                 // skeleton is the contract
    public final void run(ImportSource src) {      // final: not overridable
        Payload p = read(src);                     // fixed
        List<Row> rows = parse(p);                 // HOOK: csv vs json vs xml
        validate(rows);                           // fixed
        load(rows);                               // HOOK: db vs warehouse
        report(rows.size());                      // fixed, with hook for format
    }
    protected abstract List<Row> parse(Payload p);
    protected abstract void load(List<Row> rows);
    protected void report(int n) { /* default email summary */ }
}

The strengths are real: the invariant ordering of the flow is enforced by the base class (run is final, so no subclass can skip validation), the shared steps are written once, and a reader sees the whole algorithm in a single method. The weaknesses are structural: the variation axis is fixed at subclassing time (no runtime switching without creating a different subclass), the hooks couple subclass to base-class internals (a protected method change breaks every subclass at once — the fragile base class problem), and Java-style single inheritance means the subclass cannot also extend anything else.

Strategy pushes the variation into sibling objects selected at runtime, which is the same skeleton implemented as composition:

public final class ImportPipeline {                // no inheritance involved
    private final RowParser parser;                // strategy
    private final RowLoader loader;                // strategy
    public void run(ImportSource src) {
        List<Row> rows = parser.parse(read(src));
        validate(rows);                            // owned here, not a hook
        loader.load(rows);
    }
}

The chooser table:

Practical guidance for architecture reviews: reach for strategy when selection is data (config-driven, per-request, per-tenant) or when a step is shared by several flows; accept template method when the skeleton itself is the invariant you want enforced by the type system and the variants are closed, few, and never selected at runtime. And note the honest observation interviewers appreciate: in languages with first-class functions, many template methods and single-method strategies collapse into a passed function — the pattern remains valuable when the varying piece has structure (several methods, state-free logic worth naming), and the function is the right answer when it does not. This calibration — pattern or plain code, chosen by need — is the subject that closes the phase: Pattern Selection and Trade-offs.