Abstraction Failures Anti-Patterns — Find the Bug¶

Category: Design Anti-Patterns → Abstraction Failures — the chosen abstraction fights the problem instead of fitting it. Covers (collectively): Golden Hammer · Inner-Platform Effect · Interface Bloat · Premature Abstraction

This file is critical-reading practice. Each snippet below is a plausible chunk of real-world code in Go, Java, or Python. Read it the way a good reviewer does and answer three questions:

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

Abstraction failures are subtle. The code usually compiles, passes the happy-path test, and often looks sophisticated — a configurable rule engine, a clean strategy interface, an elegant recursive solution. The damage shows up later: a malformed rule silently evaluates wrong, a clever regex mishandles one edge case, a "not-yet-supported" interface method gets hit in production, a guessed extension point lets a caller reach an invalid state. Several snippets here contain a real functional bug caused directly by the wrong abstraction. One snippet is a deliberate trap: it looks over-abstracted but is genuinely justified — learn to tell the difference.

How to use this file: read each snippet and write your own answer before expanding the collapsible. The skill you're training is noticing when an abstraction has stopped serving the problem — not recalling a name.

Table of Contents¶

1. The rule engine that evaluates a malformed rule
2. Everything is a graph traversal
3. The repository that cannot stream
4. One strategy, invented for the first case
5. The email validator regex
6. The config-driven workflow interpreter
7. The collection that is read-only sometimes
8. The recursive directory sizer
9. The pluggable notifier with one knob
10. The clock interface
11. The in-database expression language
12. The shape hierarchy that guessed wrong
13. The JSON store built on a relational table
14. The animal interface every implementer dreads

Snippet 1 — The rule engine that evaluates a malformed rule¶

# Python — a home-grown rule engine for eligibility checks, grown over two years
def evaluate(rule, ctx):
    op = rule["op"]
    if op == "and":
        return all(evaluate(r, ctx) for r in rule["rules"])
    elif op == "or":
        return any(evaluate(r, ctx) for r in rule["rules"])
    elif op == "eq":
        return ctx.get(rule["field"]) == rule["value"]
    elif op == "gt":
        return ctx.get(rule["field"]) > rule["value"]
    elif op == "in":
        return ctx.get(rule["field"]) in rule["value"]
    # unknown op falls through

# rules are authored in a web UI and stored as JSON:
discount_rule = {"op": "and", "rules": [
    {"op": "gt", "field": "age", "value": 18},
    {"op": "eq", "field": "country", "valeu": "US"},   # typo by the rule author
]}

if evaluate(discount_rule, {"age": 25}):
    apply_discount()

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

def evaluate(rule, ctx):
    op = rule["op"]
    handler = OPS.get(op)
    if handler is None:
        raise ValueError(f"unknown op: {op!r}")           # fail loud
    return handler(rule, ctx)

def _eq(rule, ctx):
    if rule["field"] not in ctx:
        raise KeyError(f"missing field: {rule['field']}")  # not silent False
    return ctx[rule["field"]] == rule["value"]
# ...and validate every stored rule against a JSON Schema at save time.

Snippet 2 — Everything is a graph traversal¶

// Go — the author wrote a graph library last quarter and now reaches for it everywhere
// Requirement: given a list of tasks with "dependsOn" ids, return them in an order
// where dependencies come first. (A simple topological sort.)

func OrderTasks(tasks []Task) ([]Task, error) {
    g := graph.New()
    for _, t := range tasks {
        g.AddNode(t.ID)
    }
    for _, t := range tasks {
        for _, dep := range t.DependsOn {
            g.AddEdge(dep, t.ID)
        }
    }
    // graph.ShortestPath uses Dijkstra; the author picked it because it
    // "returns nodes in order" and it worked on their 3-task test case.
    path := g.ShortestPath(g.Roots()[0], g.Leaves()[0])
    out := make([]Task, 0, len(path))
    for _, id := range path {
        out = append(out, taskByID(tasks, id))
    }
    return out, nil
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

func OrderTasks(tasks []Task) ([]Task, error) {
    indeg := map[string]int{}
    children := map[string][]string{}
    for _, t := range tasks { indeg[t.ID] = 0 }
    for _, t := range tasks {
        for _, dep := range t.DependsOn {
            children[dep] = append(children[dep], t.ID)
            indeg[t.ID]++
        }
    }
    var queue, order []string
    for id, d := range indeg { if d == 0 { queue = append(queue, id) } }
    for len(queue) > 0 {
        n := queue[0]; queue = queue[1:]
        order = append(order, n)
        for _, c := range children[n] {
            indeg[c]--
            if indeg[c] == 0 { queue = append(queue, c) }
        }
    }
    if len(order) != len(tasks) {
        return nil, errors.New("dependency cycle detected")   // the real error case
    }
    return mapIDs(order, tasks), nil
}

Snippet 3 — The repository that cannot stream¶

// Java — a generic repository interface, "so every entity is consistent"
public interface Repository<T> {
    T findById(long id);
    List<T> findAll();              // <-- loads the entire table into memory
    List<T> findByExample(T probe);
    void save(T entity);
    void saveAll(List<T> entities);
    void delete(long id);
    void deleteAll();
    long count();
    boolean exists(long id);
    Page<T> findPage(int page, int size);
    Stream<T> stream();             // added later; only JdbcAuditRepository implements it
}

public class InMemoryConfigRepository implements Repository<Config> {
    private final Map<Long, Config> data = new HashMap<>();
    public List<Config> findAll() { return new ArrayList<>(data.values()); }
    public void save(Config c) { data.put(c.id(), c); }
    // ...
    public Stream<Config> stream() {
        throw new UnsupportedOperationException("not supported for in-memory");
    }
    public Page<Config> findPage(int page, int size) {
        throw new UnsupportedOperationException("paging not supported");
    }
    public List<Config> findByExample(Config probe) {
        throw new UnsupportedOperationException("query-by-example not supported");
    }
}

// In an export job that runs nightly:
void exportAll(Repository<Config> repo) {
    try (Stream<Config> s = repo.stream()) {   // <-- relies on stream()
        s.forEach(this::writeRow);
    }
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

interface Reader<T>   { T findById(long id); boolean exists(long id); }
interface Writer<T>   { void save(T e); void delete(long id); }
interface Listable<T> { List<T> findAll(); long count(); }
interface Streamable<T> { Stream<T> stream(); }   // implemented only where real

// The export job now states its true requirement in its parameter type:
void exportAll(Streamable<Config> source) {
    try (Stream<Config> s = source.stream()) { s.forEach(this::writeRow); }
}

Snippet 4 — One strategy, invented for the first case¶

# Python — added the day the first payment method (card) shipped
from abc import ABC, abstractmethod

class PaymentStrategy(ABC):
    @abstractmethod
    def authorize(self, amount): ...
    @abstractmethod
    def capture(self, amount): ...
    @abstractmethod
    def refund(self, amount): ...
    @abstractmethod
    def supports_partial_capture(self): ...   # guessed extension point

class CardPayment(PaymentStrategy):
    def authorize(self, amount):
        self._auth_id = gateway.authorize(amount)
        return self._auth_id
    def capture(self, amount):
        return gateway.capture(self._auth_id, amount)   # uses auth from authorize()
    def refund(self, amount):
        return gateway.refund(self._auth_id, amount)
    def supports_partial_capture(self):
        return True

# six months later, the second method arrives: store credit (no gateway, instant)
class StoreCreditPayment(PaymentStrategy):
    def authorize(self, amount):
        pass                                  # nothing to authorize
    def capture(self, amount):
        ledger.debit(self.account, amount)    # never calls authorize; no _auth_id
    def refund(self, amount):
        ledger.credit(self.account, amount)
    def supports_partial_capture(self):
        return True

def charge(strategy, amount):
    strategy.authorize(amount)
    strategy.capture(amount)

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

class Payment(Protocol):
    def charge(self, amount) -> Receipt: ...   # one method: the real shared operation
    def refund(self, amount) -> Receipt: ...

class CardPayment:
    def charge(self, amount):
        auth = gateway.authorize(amount)        # lifecycle is CardPayment's private detail
        return gateway.capture(auth, amount)
    def refund(self, amount): ...

class StoreCreditPayment:
    def charge(self, amount):
        ledger.debit(self.account, amount)      # no fake authorize step
        return Receipt(...)
    def refund(self, amount): ...

Snippet 5 — The email validator regex¶

# Python — the author's favorite tool is regex; reaches for it for every parse
import re

# "Validate an email and extract the domain for routing."
EMAIL_RE = re.compile(r"^(\w+)@(\w+)\.(\w+)$")

def route(email):
    m = EMAIL_RE.match(email)
    if not m:
        raise ValueError("invalid email")
    domain = m.group(2) + "." + m.group(3)
    return ROUTES.get(domain, ROUTES["default"])

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

def route(email):
    if email.count("@") == 0:
        raise ValueError("invalid email: no @")
    local, _, domain = email.rpartition("@")   # rpartition handles the real cases
    if not local or not domain:
        raise ValueError("invalid email")
    return ROUTES.get(domain.lower(), ROUTES["default"])

Snippet 6 — The config-driven workflow interpreter¶

# A "workflow engine" configured entirely in YAML, parsed by an in-house interpreter.
# Business analysts edit this file directly; engineers maintain the interpreter.
workflow:
  - step: fetch_order
    assign: order
  - step: branch
    if: "${order.total} > 100"
    then:
      - step: set
        var: shipping
        value: "0"
      - step: call
        fn: notify_premium
    else:
      - step: set
        var: shipping
        value: "9.99"
  - step: loop
    over: "${order.items}"
    do:
      - step: call
        fn: reserve_stock
        args: ["${item.sku}"]      # note: 'item' loop variable

# the interpreter — excerpt
def run_step(step, scope):
    if step["step"] == "branch":
        if eval_expr(step["if"], scope):           # eval_expr does string substitution + eval()
            for s in step["then"]: run_step(s, scope)
        else:
            for s in step["else"]: run_step(s, scope)   # KeyError if no 'else'
    elif step["step"] == "loop":
        for it in eval_expr(step["over"], scope):
            scope["item"] = it                     # leaks into outer scope; never cleaned up
            for s in step["do"]: run_step(s, scope)

def eval_expr(expr, scope):
    for k, v in scope.items():
        expr = expr.replace("${" + k + "}", repr(v))
    return eval(expr)                              # arbitrary code execution

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

# the "real code" route — the workflow is just a function
def process_order(order):
    shipping = 0 if order.total > 100 else 9.99
    if order.total > 100:
        notify_premium(order)
    for item in order.items:        # 'item' is properly scoped to the loop
        reserve_stock(item.sku)
    return shipping

Snippet 7 — The collection that is read-only sometimes¶

// Java — a domain collection wrapper used across the order module
public interface OrderLines extends List<OrderLine> {
    BigDecimal total();
}

// the concrete type returned by a *finalized* (immutable) order:
public final class FinalizedOrderLines extends AbstractList<OrderLine>
        implements OrderLines {
    private final List<OrderLine> lines;
    FinalizedOrderLines(List<OrderLine> lines) { this.lines = List.copyOf(lines); }

    public OrderLine get(int i) { return lines.get(i); }
    public int size()           { return lines.size(); }
    public BigDecimal total()   { return lines.stream().map(OrderLine::amount)
                                              .reduce(ZERO, BigDecimal::add); }

    @Override public boolean add(OrderLine l) {
        throw new UnsupportedOperationException("order is finalized");
    }
    @Override public OrderLine set(int i, OrderLine l) {
        throw new UnsupportedOperationException("order is finalized");
    }
    @Override public OrderLine remove(int i) {
        throw new UnsupportedOperationException("order is finalized");
    }
}

// a generic discount routine, written against List, reused for finalized orders:
void applyLineDiscount(List<OrderLine> lines, BigDecimal pct) {
    for (int i = 0; i < lines.size(); i++) {
        lines.set(i, lines.get(i).discounted(pct));   // <-- mutates in place
    }
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

public interface OrderLines extends Iterable<OrderLine> {   // no mutators inherited
    OrderLine get(int i);
    int size();
    BigDecimal total();
}

// discount becomes a pure transformation, not an in-place mutation:
List<OrderLine> discounted(OrderLines lines, BigDecimal pct) {
    var out = new ArrayList<OrderLine>(lines.size());
    for (OrderLine l : lines) out.add(l.discounted(pct));
    return out;                       // caller decides what to do with a new list
}

Snippet 8 — The recursive directory sizer¶

// Go — "compute total size of a directory tree". The author loves recursion.
func DirSize(path string) (int64, error) {
    entries, err := os.ReadDir(path)
    if err != nil {
        return 0, err
    }
    var total int64
    for _, e := range entries {
        full := filepath.Join(path, e.Name())
        if e.IsDir() {
            sub, err := DirSize(full)        // recurse per subdirectory
            if err != nil {
                return 0, err
            }
            total += sub
        } else {
            info, _ := e.Info()
            total += info.Size()
        }
    }
    return total, nil
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

func DirSize(root string) (int64, error) {
    var total int64
    err := filepath.WalkDir(root, func(_ string, d os.DirEntry, err error) error {
        if err != nil {
            return err                       // surface every error; don't swallow
        }
        if !d.IsDir() {
            info, err := d.Info()
            if err != nil {
                return err
            }
            total += info.Size()
        }
        return nil
    })
    return total, err
}

Snippet 9 — The pluggable notifier with one knob¶

# Python — written when the only notifier was email; "made flexible for the future"
from abc import ABC, abstractmethod

class NotificationChannel(ABC):
    @abstractmethod
    def build_payload(self, user, message): ...
    @abstractmethod
    def transport(self): ...
    @abstractmethod
    def retry_policy(self): ...
    @abstractmethod
    def rate_limit(self): ...
    @abstractmethod
    def serialize(self, payload): ...
    @abstractmethod
    def template_engine(self): ...

class EmailChannel(NotificationChannel):
    def build_payload(self, user, message):
        return {"to": user.email, "subject": "Notice", "body": message}
    def transport(self):       return self._smtp
    def retry_policy(self):    return ExponentialBackoff(max=3)
    def rate_limit(self):      return None
    def serialize(self, p):    return mime_encode(p)
    def template_engine(self): return self._jinja

# six months later, the second channel arrives: SMS.
class SmsChannel(NotificationChannel):
    def build_payload(self, user, message):
        return {"to": user.phone, "text": message[:160]}   # SMS truncates at 160
    def transport(self):       return self._twilio
    def retry_policy(self):    return ExponentialBackoff(max=3)   # copied from email
    def rate_limit(self):      return None
    def serialize(self, p):    return p                    # no MIME for SMS
    def template_engine(self): return None                 # SMS has no templates!

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

class NotificationChannel(Protocol):
    def send(self, user, message: str) -> None: ...   # the only real commonality

class EmailChannel:
    def send(self, user, message):
        payload = {"to": user.email, "subject": "Notice", "body": message}
        self._smtp.send(self._jinja.render(payload))   # templating is email's detail

class SmsChannel:
    def send(self, user, message):
        self._twilio.send(user.phone, message[:160])   # truncation is SMS's detail

Snippet 10 — The clock interface¶

// Go — a tiny interface in a billing package; reviewer flags it as "over-abstraction"
type Clock interface {
    Now() time.Time
}

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

// production wiring:
func NewBillingService() *BillingService {
    return &BillingService{clock: realClock{}}
}

type BillingService struct{ clock Clock }

func (s *BillingService) IsOverdue(inv Invoice) bool {
    return s.clock.Now().After(inv.DueDate)
}

// in tests:
type fixedClock struct{ t time.Time }
func (c fixedClock) Now() time.Time { return c.t }

func TestIsOverdue(t *testing.T) {
    svc := &BillingService{clock: fixedClock{t: parse("2024-01-15")}}
    if !svc.IsOverdue(Invoice{DueDate: parse("2024-01-10")}) {
        t.Fatal("expected overdue")
    }
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

Snippet 11 — The in-database expression language¶

-- A "calculated columns" feature. Users define formulas in a web UI; the app stores
-- them and evaluates them inside a stored procedure that walks a custom AST table.

CREATE TABLE formula_node (
    id          INT PRIMARY KEY,
    formula_id  INT,
    node_type   VARCHAR(16),   -- 'const' | 'col' | 'add' | 'mul' | 'div' | 'if'
    value       VARCHAR(64),   -- meaning depends on node_type
    left_id     INT,           -- child node ids
    right_id    INT,
    cond_id     INT
);

# the evaluator the app runs for every row of every report:
def eval_node(node_id, row):
    node = fetch_node(node_id)               # one DB round-trip per node
    t = node["node_type"]
    if t == "const":
        return float(node["value"])
    if t == "col":
        return row[node["value"]]
    if t == "add":
        return eval_node(node["left_id"], row) + eval_node(node["right_id"], row)
    if t == "mul":
        return eval_node(node["left_id"], row) * eval_node(node["right_id"], row)
    if t == "div":
        return eval_node(node["left_id"], row) / eval_node(node["right_id"], row)
    if t == "if":
        if eval_node(node["cond_id"], row):
            return eval_node(node["left_id"], row)
        return eval_node(node["right_id"], row)

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

import ast, operator

# compile the formula text ONCE into a safe callable, then apply to every row in-process
_OPS = {ast.Add: operator.add, ast.Mult: operator.mul, ast.Div: operator.truediv}

def compile_formula(expr_text):
    tree = ast.parse(expr_text, mode="eval")      # parse once
    def run(row):
        return _eval(tree.body, row)              # no DB round-trips per node
    return run
# (_eval validates node types, rejects unknown ops, and guards division)

Snippet 12 — The shape hierarchy that guessed wrong¶

// Java — a geometry module. The abstraction was designed up front from one example (Circle).
public abstract class Shape {
    protected double radius;                  // <-- assumed every shape has a radius

    public Shape(double radius) { this.radius = radius; }

    public abstract double area();

    public double diameter() { return 2 * radius; }      // "every shape has one", apparently
    public void scale(double f) { this.radius *= f; }    // scaling = grow the radius
}

public class Circle extends Shape {
    public Circle(double r) { super(r); }
    public double area() { return Math.PI * radius * radius; }
}

// added later — the second shape reveals the abstraction was guessed:
public class Rectangle extends Shape {
    private double width, height;
    public Rectangle(double w, double h) {
        super(w / 2);                         // <-- fake a "radius" to satisfy super()
        this.width = w; this.height = h;
    }
    public double area() { return width * height; }
    // inherits diameter() and scale() from Shape...
}

// generic code that resizes any shape, written against Shape:
void resize(Shape s, double factor) { s.scale(factor); }

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

public interface Shape {
    double area();
    Shape scaled(double factor);     // each shape knows how to scale itself, immutably
}

public final class Circle implements Shape {
    private final double radius;
    public Circle(double r) { this.radius = r; }
    public double area() { return Math.PI * radius * radius; }
    public Shape scaled(double f) { return new Circle(radius * f); }
}

public final class Rectangle implements Shape {
    private final double width, height;
    public Rectangle(double w, double h) { this.width = w; this.height = h; }
    public double area() { return width * height; }
    public Shape scaled(double f) { return new Rectangle(width * f, height * f); }
}

Snippet 13 — The JSON store built on a relational table¶

# Python — "we need flexible, schemaless storage", built on top of PostgreSQL
# by storing every entity as key/value rows in one EAV table.

# table: attribute(entity_id, entity_type, key, value TEXT)

def save_entity(entity_type, entity_id, obj: dict):
    for k, v in obj.items():
        db.execute(
            "INSERT INTO attribute(entity_id, entity_type, key, value) VALUES (%s,%s,%s,%s) "
            "ON CONFLICT (entity_id, key) DO UPDATE SET value = EXCLUDED.value",
            (entity_id, entity_type, k, str(v)),     # everything stringified
        )

def load_entity(entity_type, entity_id):
    rows = db.query(
        "SELECT key, value FROM attribute WHERE entity_id=%s AND entity_type=%s",
        (entity_id, entity_type),
    )
    return {r["key"]: r["value"] for r in rows}      # everything comes back as str

# usage:
save_entity("order", 42, {"total": 100.0, "paid": True, "items": 3})
order = load_entity("order", 42)
if order["paid"]:                                    # <-- always truthy!
    ship(order)

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

CREATE TABLE orders (
    id     BIGINT PRIMARY KEY,
    total  NUMERIC(12,2) NOT NULL,
    paid   BOOLEAN       NOT NULL DEFAULT FALSE,   -- real boolean, no "True"/"False" strings
    items  INT           NOT NULL
);
-- need flexible extra fields? use a typed JSONB column, not an EAV table:
ALTER TABLE orders ADD COLUMN meta JSONB;

order = load_order(42)        # paid comes back as a real bool
if order.paid:                # correct: False is falsy, True is truthy
    ship(order)

Snippet 14 — The animal interface every implementer dreads¶

// Java — an interface in a zoo-simulation engine, "so all animals are uniform"
public interface Animal {
    void walk();
    void run();
    void swim();
    void fly();
    void climb();
    void burrow();
    String sound();
    void eat(Food f);
}

public class Penguin implements Animal {
    public void walk() { /* waddle */ }
    public void run()  { /* ... */ }
    public void swim() { /* ... */ }
    public void fly()  { throw new UnsupportedOperationException("penguins can't fly"); }
    public void climb(){ throw new UnsupportedOperationException(); }
    public void burrow(){ throw new UnsupportedOperationException(); }
    public String sound() { return "squawk"; }
    public void eat(Food f) { /* ... */ }
}

// the migration scheduler moves every animal to its winter habitat:
void migrate(List<Animal> animals) {
    for (Animal a : animals) {
        a.fly();                        // "all migrating animals fly south"
    }
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

interface Animal   { String sound(); void eat(Food f); }   // truly universal
interface Walker   { void walk(); void run(); }
interface Swimmer  { void swim(); }
interface Flyer    { void fly(); }
interface Climber  { void climb(); }
interface Burrower { void burrow(); }

class Penguin implements Animal, Walker, Swimmer {          // only what it can do
    public void walk() {}  public void run() {}  public void swim() {}
    public String sound() { return "squawk"; }  public void eat(Food f) {}
}

// migrate now states its real requirement in the type — and can't be handed a Penguin:
void migrate(List<Flyer> flyers) {
    for (Flyer f : flyers) f.fly();
}

Summary — patterns of spotting¶

Abstraction failures don't announce themselves with a crash on line one. They look clean, configurable, or clever, and the damage surfaces later — often as a silent functional bug. The repeatable diagnostic moves from these fourteen snippets:

• Watch for the platform being rebuilt inside the platform. If you find variables, control flow, an expression evaluator, an AST-in-a-table, or a key/value store implemented on top of a language or database that already provides all of those — that's the Inner-Platform Effect (Snippets 1, 6, 11, 13). The tell is a generic, configurable mechanism reimplementing something the host gives you for free, and the recurring bug is silent mis-evaluation of a malformed or edge-case input (a misspelled rule, a missing else, division by zero, a stringified boolean that ships an unpaid order).
• Ask whether the tool fits the problem, not the author's habits. A graph library used for the wrong graph algorithm, regex used to parse a non-regular format, recursion chosen before the operational questions are asked — these are Golden Hammers (Snippets 2, 5, 8). The wrong tool doesn't just under-perform; it produces wrong answers on the edge cases it was never suited for (dropped tasks, mis-routed mail, symlink loops, swallowed errors).
• Count UnsupportedOperationException / raise NotImplementedError / return None stubs. Every method an implementer is forced to refuse is a sign the interface promised more than it can deliver — Interface Bloat (Snippets 3, 7, 9, 14). The bug pattern is identical every time: code written against the wide interface calls the refused method and crashes at runtime, because the type system advertised a capability the object doesn't have. The cure is always Interface Segregation — split into role interfaces so misuse becomes a compile error.
• Find abstractions extracted from a single example, then check the second case. A base class, strategy, or interface designed up front or from one implementation bakes that case's accidents into the universal contract — Premature Abstraction (Snippets 4, 9, 12). The second concrete case can't fit the guessed shape, so it fakes fields (super(w/2)), returns None for meaningless methods, or hides a lifecycle invariant that lets a caller reach an invalid state (an unscaled rectangle, an unset _auth_id). Honor the rule of three.
• Resist false positives. A small, stable, minimal interface introduced to break a hard dependency for testing — a Clock, a fake repository — is good design, not over-abstraction (Snippet 10). Abstractions are judged by whether they do work today, not by their shape. Count the real consumers (including tests) and check the surface for speculative width before crying "premature."

The meta-lesson: the wrong abstraction is more dangerous than no abstraction, because it looks like a decision was made well. A custom rule engine silently denied eligibility; a Golden-Hammer regex mis-routed real users' mail; a bloated interface threw at 2 a.m.; a guessed strategy let a payment reach an unset state; an EAV store shipped an unpaid order. When an abstraction feels elegant, ask the hard question anyway: does this shape fit the problem, or just the tool I reached for?

Related Topics¶

• tasks.md — design exercises that build the same muscles from the writing side.
• ../01-oo-misuse/find-bug.md — sibling find-bug file (Anemic Model, Magic Container, Flag Arguments, …).
• ../02-coupling-and-state/find-bug.md — sibling find-bug file (Singletonitis, Hidden Dependencies, …).
• Clean Code → Classes (SOLID, ISP) — the Interface Segregation cure for bloated interfaces.
• Design Patterns → Structural — Adapter, Facade, and composition as alternatives to fat interfaces.
• Design Patterns → Behavioral — Strategy done right, after the rule of three.
• Refactoring → Code Smells — Speculative Generality and Refused Bequest, the smell-level view.
• Algorithms → Graphs — which graph algorithm fits which problem (the Golden-Hammer antidote).