Premature Abstraction at Scale — Practice Tasks¶

Category: Anti-Patterns at Scale → Premature Abstraction at Scale Covers (collectively): Speculative Generality · Wrapper-itis & needless indirection · Premature decoupling & one-implementation interfaces · The Wrong Abstraction · AHA / Rule of Three / YAGNI as the cure

These are judgment-and-removal exercises. The dominant move is to subtract — inline a one-implementation interface back to concrete, collapse a wrong abstraction's flag parameters, and decide which duplications are the same concept (extract) versus coincidental (leave). One exercise deliberately gives you a justified abstraction whose correct answer is keep it — reflexive deletion is its own anti-pattern, and the skill here is telling the cases apart.

Each exercise has a problem statement, starting code (Go, Java, Python, or TypeScript — the language varies on purpose), acceptance criteria, and a collapsible solution with the reasoning. Try it in your editor before expanding. Where a change is mechanical and repeated across many files, the solution notes how you'd do it at scale (see Automated Large-Scale Refactoring).

Through-line: abstraction is not free and duplication is not evil. The win condition is easier to change, not fewer characters. Re-read senior.md for the cost model and the unwinding playbook.

Table of Contents¶

Exercise 1 — Inline the one-implementation interface¶

Anti-pattern: One-implementation interface · Language: Go · Difficulty: ★ easy

A teammate "decoupled" a slug generator behind an interface "in case we need a different slugging strategy." There is one implementation, no second on the roadmap, and the impl is pure (no I/O). Restore the concrete form.

package slug

type Slugger interface {
    Slug(s string) string
}

type DefaultSlugger struct{}

func (DefaultSlugger) Slug(s string) string {
    s = strings.ToLower(strings.TrimSpace(s))
    return strings.ReplaceAll(s, " ", "-")
}

// Wired everywhere:
//   var sl slug.Slugger = slug.DefaultSlugger{}
//   path := sl.Slug(title)

Acceptance criteria

• No interface; one exported function.
• Call sites become slug.Make(title) (or similar) with no instance to construct.
• Behavior identical.

package slug

func Make(s string) string {
    s = strings.ToLower(strings.TrimSpace(s))
    return strings.ReplaceAll(s, " ", "-")
}

// Call sites:
//   path := slug.Make(title)

Exercise 2 — Rule of Three: extract or wait?¶

Anti-pattern: Premature extraction (judgment) · Language: Python · Difficulty: ★ easy

You're reviewing a PR. The author found two functions that both compute a "display total" and wants to extract a shared compute_total. Apply the Rule of Three and the same-knowledge test to decide.

# In cart.py
def cart_display_total(items):
    subtotal = sum(i.price * i.qty for i in items)
    return round(subtotal * 1.08, 2)   # 8% sales tax

# In invoice.py
def invoice_display_total(lines):
    subtotal = sum(l.amount for l in lines)
    return round(subtotal * 1.08, 2)   # 8% sales tax

Acceptance criteria

• Decide: extract now, or wait? Justify with the same-knowledge test, not the syntax.
• If you extract, say what is shared and what isn't.

# tax.py — the single authoritative representation of the tax rule
SALES_TAX_RATE = 0.08

def apply_sales_tax(subtotal):
    return round(subtotal * (1 + SALES_TAX_RATE), 2)

# cart.py
def cart_display_total(items):
    return apply_sales_tax(sum(i.price * i.qty for i in items))

# invoice.py
def invoice_display_total(lines):
    return apply_sales_tax(sum(l.amount for l in lines))

Exercise 3 — Four duplications — which are the same concept?¶

Anti-pattern: DRY vs coincidental duplication · Language: TypeScript · Difficulty: ★★ medium

Below are four pairs of near-identical code. For each, decide extract (same knowledge) or leave (coincidental), using one test: if the requirement behind one changed, would the other have to change too?

// PAIR A — two validators
function isValidEmail(s: string) { return /^[^@]+@[^@]+\.[^@]+$/.test(s); }
function isValidContactEmail(s: string) { return /^[^@]+@[^@]+\.[^@]+$/.test(s); }

// PAIR B — two "is this a weekend" checks
function reportIsWeekend(d: Date) { const x = d.getDay(); return x === 0 || x === 6; }
function billingIsWeekend(d: Date) { const x = d.getDay(); return x === 0 || x === 6; }

// PAIR C — two DTO shapes that currently match
interface CreateUserRequest { name: string; email: string; age: number; }
interface UserRow         { name: string; email: string; age: number; }

// PAIR D — two retry loops
async function fetchWithRetry(fn: () => Promise<Resp>) {
  for (let i = 0; i < 3; i++) { try { return await fn(); } catch { await sleep(2 ** i * 100); } }
  throw new Error("exhausted");
}
async function publishWithRetry(fn: () => Promise<void>) {
  for (let i = 0; i < 3; i++) { try { return await fn(); } catch { await sleep(2 ** i * 100); } }
  throw new Error("exhausted");
}

Acceptance criteria

• A verdict (extract / leave) for each pair, with the one-sentence justification.

Exercise 4 — Inline the wrong abstraction¶

Anti-pattern: The Wrong Abstraction · Language: Java · Difficulty: ★★ medium

A formatName method was extracted from two call sites long ago. Since then it has grown flags as each caller needed "almost the same" output. No caller uses more than one path. Inline it back to honest, concrete methods.

public String formatName(Person p, boolean lastFirst, boolean withTitle, boolean initialsOnly) {
    String first = p.getFirst();
    String last = p.getLast();
    if (initialsOnly) {
        return ("" + first.charAt(0) + last.charAt(0)).toUpperCase();
    }
    String name = lastFirst ? last + ", " + first : first + " " + last;
    if (withTitle && p.getTitle() != null) {
        name = p.getTitle() + " " + name;
    }
    return name;
}

// The only three call sites in the codebase:
//   greeting   = formatName(p, false, true,  false);   // "Dr. Ada Lovelace"
//   sortKey    = formatName(p, true,  false, false);   // "Lovelace, Ada"
//   avatarText = formatName(p, false, false, true);    // "AL"

Acceptance criteria

• Three concrete methods, each with no boolean parameters.
• Each method contains only the logic its caller actually exercises.
• The flags disappear entirely.

public String greetingName(Person p) {           // was formatName(p,false,true,false)
    String name = p.getFirst() + " " + p.getLast();
    return p.getTitle() != null ? p.getTitle() + " " + name : name;
}

public String sortKey(Person p) {                // was formatName(p,true,false,false)
    return p.getLast() + ", " + p.getFirst();
}

public String avatarInitials(Person p) {         // was formatName(p,false,false,true)
    return ("" + p.getFirst().charAt(0) + p.getLast().charAt(0)).toUpperCase();
}

Exercise 5 — Collapse the wrapper chain¶

Anti-pattern: Wrapper-itis / needless indirection · Language: Go · Difficulty: ★★ medium

A request to fetch a user travels through four layers, each of which only forwards the call. Collapse the chain to the one layer that does real work.

type UserController struct{ svc *UserService }
func (c *UserController) Get(id string) (*User, error) { return c.svc.GetUser(id) }

type UserService struct{ mgr *UserManager }
func (s *UserService) GetUser(id string) (*User, error) { return s.mgr.FetchUser(id) }

type UserManager struct{ repo *UserRepository }
func (m *UserManager) FetchUser(id string) (*User, error) { return m.repo.LoadUser(id) }

type UserRepository struct{ db *sql.DB }
func (r *UserRepository) LoadUser(id string) (*User, error) {
    row := r.db.QueryRow("SELECT id, name FROM users WHERE id = $1", id)
    var u User
    if err := row.Scan(&u.ID, &u.Name); err != nil {
        return nil, err
    }
    return &u, nil
}

Acceptance criteria

• Eliminate layers that only forward.
• Keep the layer that does real work (the SQL).
• The controller calls the repository directly (or through at most one layer that earns its place).

type UserController struct{ repo *UserRepository }

func (c *UserController) Get(id string) (*User, error) {
    return c.repo.LoadUser(id)
}

type UserRepository struct{ db *sql.DB }

func (r *UserRepository) LoadUser(id string) (*User, error) {
    row := r.db.QueryRow("SELECT id, name FROM users WHERE id = $1", id)
    var u User
    if err := row.Scan(&u.ID, &u.Name); err != nil {
        return nil, err
    }
    return &u, nil
}

Exercise 6 — Keep it or kill it? (the trap)¶

Anti-pattern: Justified abstraction (judgment) · Language: Go · Difficulty: ★★ medium

A reviewer flagged this interface as "premature decoupling — delete it, there's one implementation." Decide whether to delete it. Read the surrounding facts carefully.

// Clock lets time-dependent code be tested deterministically.
type Clock interface {
    Now() time.Time
}

type SystemClock struct{}
func (SystemClock) Now() time.Time { return time.Now() }

// In tests:
type fakeClock struct{ t time.Time }
func (f fakeClock) Now() time.Time { return f.t }

// Used by token-expiry logic, rate limiters, and scheduled-job code.
func (s *Session) Expired(c Clock) bool {
    return c.Now().After(s.ExpiresAt)
}

Acceptance criteria

• A verdict: keep or delete.
• Justify against the "earns its keep" checklist — don't reflexively delete.

Exercise 7 — Strip the speculative plugin system¶

Anti-pattern: Speculative Generality · Language: Python · Difficulty: ★★★ hard

A "pluggable report exporter framework" was built to support future formats. Two years on, there is exactly one plugin (CSV), and the registry/discovery machinery has never had a second entry. Strip it to the concrete behavior, preserving the public export_report call.

import importlib, pkgutil

class ExporterPlugin:
    name: str
    def export(self, report) -> bytes:
        raise NotImplementedError

class ExporterRegistry:
    def __init__(self):
        self._plugins = {}
    def register(self, plugin: ExporterPlugin):
        self._plugins[plugin.name] = plugin
    def discover(self, package):
        for _, modname, _ in pkgutil.iter_modules(package.__path__):
            mod = importlib.import_module(f"{package.__name__}.{modname}")
            if hasattr(mod, "PLUGIN"):
                self.register(mod.PLUGIN)
    def get(self, name): return self._plugins[name]

# plugins/csv_exporter.py
class CsvExporter(ExporterPlugin):
    name = "csv"
    def export(self, report) -> bytes:
        rows = ["{},{}".format(r.label, r.value) for r in report.rows]
        return "\n".join(rows).encode("utf-8")
PLUGIN = CsvExporter()

# Public API, the only call site:
def export_report(report, fmt="csv"):
    registry = ExporterRegistry()
    registry.discover(plugins)
    return registry.get(fmt).export(report)

Acceptance criteria

• export_report(report) keeps working and returns the same bytes.
• No registry, no plugin base class, no dynamic discovery.
• A clear comment on where the extension point goes if a second format ever becomes real.

def export_report(report, fmt="csv"):
    if fmt != "csv":
        raise ValueError(f"unsupported format: {fmt}")
    rows = ["{},{}".format(r.label, r.value) for r in report.rows]
    return "\n".join(rows).encode("utf-8")

def export_report(report, fmt="csv"):
    exporters = {"csv": _to_csv, "json": _to_json}
    try:
        return exporters[fmt](report)
    except KeyError:
        raise ValueError(f"unsupported format: {fmt}")

Exercise 8 — Unwind a wrong abstraction across call sites¶

Anti-pattern: Wrong Abstraction at scale · Language: Java · Difficulty: ★★★ hard

A shared NotificationSender.send is called from 30+ places. It grew a channel enum and per-channel branches; callers always pass a constant channel. The branches have diverged so far that the "shared" method shares almost nothing. Outline and demonstrate the safe, incremental unwinding — not a big-bang rewrite.

public enum Channel { EMAIL, SMS, PUSH }

public class NotificationSender {
    public void send(Channel ch, User u, String body) {
        if (ch == Channel.EMAIL) {
            String html = renderHtml(body);
            smtp.send(u.getEmail(), subjectFor(u), html);
            audit.log("email", u.getId());
        } else if (ch == Channel.SMS) {
            String text = truncate(body, 160);
            twilio.sms(u.getPhone(), text);
        } else if (ch == Channel.PUSH) {
            fcm.push(u.getDeviceToken(), new Payload(body));
            metrics.increment("push.sent");
        }
    }
}

// Call sites, always constant channel:
//   sender.send(Channel.EMAIL, user, "Your order shipped");
//   sender.send(Channel.SMS,   user, "Code: 1234");
//   sender.send(Channel.PUSH,  user, "You have a match");

Acceptance criteria

• Describe the steps so each is independently shippable and behavior-preserving.
• Show the target shape (three concrete senders, no Channel parameter).
• Note how you'd execute the call-site migration mechanically and where fitness functions/budgets lock it in.

public class EmailNotifier {
    public void send(User u, String body) {
        smtp.send(u.getEmail(), subjectFor(u), renderHtml(body));
        audit.log("email", u.getId());
    }
}
public class SmsNotifier {
    public void send(User u, String body) {
        twilio.sms(u.getPhone(), truncate(body, 160));
    }
}
public class PushNotifier {
    public void send(User u, String body) {
        fcm.push(u.getDeviceToken(), new Payload(body));
        metrics.increment("push.sent");
    }
}

Summary¶

• The dominant move against premature abstraction is subtraction: inline one-impl interfaces, collapse empty wrapper layers, and re-introduce honest duplication to dissolve a wrong abstraction.
• DRY targets the same knowledge, not the same text. Exercise 3's most-identical pair (the DTOs) is the one to leave; the discriminator is always "would a change to one force a change to the other?", never syntactic similarity.
• The Rule of Three is a heuristic about uncertainty — override it (extract at two) when the duplication is the same knowledge and divergence is a correctness bug (Exercise 2).
• Not every abstraction is premature. Exercise 6's Clock is a justified seam — a real fake in tests over a non-deterministic boundary. Reflexive deletion is its own anti-pattern; the skill is judgment.
• At scale, unwind incrementally: characterize → expand (new concrete forms) → migrate call sites mechanically, one slice per PR → contract (delete the dead abstraction) → ratchet. The collapse is the cheap last step, not the risky first one.

Related Topics¶

• Over-Engineering → Tasks — the in-the-file simplification drills these scale up.
• Automated Large-Scale Refactoring — the tooling to collapse flags and migrate call sites mechanically.
• Expand-Contract Refactors — removing a parameter or interface across many callers safely.
• Strangler Fig & Seams — characterization tests, the safety net for any unwinding.
• Hotspot Analysis — decide which wrong abstraction is worth the unwinding budget.
• Architecture → Anti-Patterns — system-level over-abstraction.
• Level files: senior.md — the cost model and full unwinding playbook these exercises practice.