When to Refactor to Patterns — Decision Tasks¶

Source: Joshua Kerievsky, Refactoring to Patterns (Addison-Wesley, 2004); refactoring.guru/design-patterns

These are judgment exercises, not coding drills. For each: given a snippet and its context, decide if you'd refactor to a pattern, which pattern, or argue NOT to. Justify with the smell, the rule of three, and cost/benefit. A full discussion follows each task after the divider. Cover the answer before reading.

Task 1 — The duplicated dispatch¶

Context: This switch (type()) appears in three methods of Account (interestRate(), withdrawalLimit(), monthlyFee()). The bank adds a new account type roughly twice a year.

double interestRate() {
    switch (type()) {
        case CHECKING: return 0.001;
        case SAVINGS:  return 0.02;
        case CD:       return 0.04;
        default: throw new IllegalStateException();
    }
}
// ...same switch in withdrawalLimit() and monthlyFee()

Decide: Pattern or not? Which? Justify.

Task 2 — The lonely conditional¶

Context: This is the only place in the codebase that branches on level. It hasn't changed in 18 months. Three branches.

String badge(int level) {
    if (level < 10)  return "bronze";
    if (level < 50)  return "silver";
    return "gold";
}

Decide: Pattern or not?

Task 3 — The optional embellishments¶

Context: Coffee pricing. Customers can add milk, soy, an extra shot, whipped cream — in any combination. New add-ons appear a few times a year.

BigDecimal price(Order o) {
    BigDecimal p = base(o.size());
    if (o.hasMilk())   p = p.add(new BigDecimal("0.50"));
    if (o.hasSoy())    p = p.add(new BigDecimal("0.60"));
    if (o.extraShot()) p = p.add(new BigDecimal("0.80"));
    if (o.whipped())   p = p.add(new BigDecimal("0.40"));
    return p;
}

Decide: Pattern or not? Which? And what's the trap?

BigDecimal price(Order o) {
    return o.addOns().stream()
            .map(AddOn::price)
            .reduce(base(o.size()), BigDecimal::add);
}

Task 4 — The state machine in disguise¶

Context: An order's behavior depends on its status, and each status determines which transitions are legal and what happens next.

void ship(Order o) {
    if (o.status() == PAID) {
        o.setStatus(SHIPPED);
        notifyCarrier(o);
    } else if (o.status() == PLACED) {
        throw new IllegalStateException("not paid");
    } else if (o.status() == SHIPPED) {
        throw new IllegalStateException("already shipped");
    }
    // similar status-branching in pay(), cancel(), deliver()...
}

Decide: Pattern or not? Strategy or State? Justify.

Task 5 — The telescoping constructor¶

Context: A Report with many optional fields. Callers pass null for fields they don't want, and the team keeps getting the argument order wrong.

new Report(title, null, footer, null, true, null, "A4", false);

Decide: Pattern or not? Which?

Report r = Report.builder()
    .title(title).footer(footer)
    .pageSize("A4").landscape(true)
    .build();

Task 6 — The premature plugin system¶

Context: A junior submits this for a notification feature. Today the product sends email. Only email. There is no ticket, no roadmap item, for any other channel.

interface NotificationStrategy { void send(User u, String msg); }
class EmailStrategy implements NotificationStrategy { /* ... */ }
class NotificationContext {
    private NotificationStrategy strategy;
    void setStrategy(NotificationStrategy s) { this.strategy = s; }
    void notify(User u, String msg) { strategy.send(u, msg); }
}

Decide: Approve, or push back?

Task 7 — The hard-coded tree¶

Context: A filesystem-like menu rendered with nested checks everywhere.

long size(Object node) {
    if (node instanceof File) return ((File) node).bytes();
    if (node instanceof Folder) {
        long total = 0;
        for (Object child : ((Folder) node).children())
            total += size(child);   // recursion already here, plus instanceof
        return total;
    }
    throw new IllegalArgumentException();
}
// the same File/Folder instanceof appears in render(), count(), search()...

Decide: Pattern or not? Which?

Task 8 — The almost-identical algorithms¶

Context: Two report exporters share the same skeleton — open, write header, write rows, write footer, close — differing only in how a row is formatted.

class CsvExporter {
    String export(List<Row> rows) {
        StringBuilder sb = new StringBuilder();
        sb.append(header());
        for (Row r : rows) sb.append(r.a()).append(",").append(r.b()).append("\n");
        sb.append(footer());
        return sb.toString();
    }
}
class TsvExporter { /* identical except "," → "\t" */ }

Decide: Pattern or not? Which? And is two enough?

String export(List<Row> rows, String delimiter) { /* one method, delimiter passed in */ }

Task 9 — The smell that's actually a model problem¶

Context: A taxRate(Customer c) method has a 40-line conditional on c.country(), and the same country-branching also appears in currency(), dateFormat(), addressFormat(), and phoneValidator() — spread across five unrelated classes.

Decide: Refactor each site to a pattern? Or something else?

Task 10 — Refactor away: the one-strategy strategy¶

Context: You inherit this. Git history shows DiscountStrategy has had exactly one implementation, NoDiscount, for two years. No others were ever added.

interface DiscountStrategy { BigDecimal apply(BigDecimal total); }
class NoDiscount implements DiscountStrategy {
    public BigDecimal apply(BigDecimal total) { return total; }
}
class Checkout {
    private DiscountStrategy discount = new NoDiscount();
    BigDecimal total(Cart c) { return discount.apply(c.subtotal()); }
}

Decide: Leave it, or refactor away?

class Checkout {
    BigDecimal total(Cart c) { return c.subtotal(); }
}