OO Misuse Anti-Patterns — Find the Bug¶

Category: Design Anti-Patterns → OO Misuse — object-orientation applied as procedure-with-classes, with the encapsulation turned inside-out. Covers (collectively): Anemic Domain Model · BaseBean · Constant Interface · Poltergeist · Object Orgy · Functional Decomposition · Call Super · Magic Container · Flag Arguments · Telescoping Constructor · Fragile Base Class

This file is critical-reading practice. Each snippet below is a plausible chunk of real-world code in Go, Java, or Python. Your job is to 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?

OO-misuse anti-patterns are class-shaped mistakes: the responsibilities are allocated wrongly, the encapsulation leaks, or the inheritance contract is unwritten. The "bug" is rarely a crash on line one — but bad object design hides and causes real functional bugs, and several snippets here contain one: a forgotten super call that breaks an invariant, a base-class change that silently corrupts a subclass, a stringly-typed map key that NPEs in production, a flag argument flipped the wrong way. A few snippets are deliberate traps — code that looks like an anti-pattern but is the right call in context. Read slowly, decide, then open the answer.

How to use this file: read each snippet and write your own answer before expanding the collapsible. The skill you're training is noticing the shape — and proving the bug to yourself — not recalling the name.

Table of Contents¶

1. The order that priced itself elsewhere
2. The base class everything extends
3. The constants everyone implements
4. The manager that just delegates
5. The event everyone can edit
6. The class full of statics
7. The lifecycle hook that must call super
8. The context bag
9. The transfer with a boolean
10. The notification constructors
11. The base class that added a field
12. The wallet that trusts its caller
13. The audited repository
14. The DTO with no behavior
15. The private helper with a flag

Snippet 1 — The order that priced itself elsewhere¶

// Java — an "Order" domain object and the service that operates on it
public class Order {
    private List<LineItem> items = new ArrayList<>();
    private OrderStatus status = OrderStatus.DRAFT;
    private BigDecimal total = BigDecimal.ZERO;

    public List<LineItem> getItems()        { return items; }
    public void setItems(List<LineItem> i)  { this.items = i; }
    public OrderStatus getStatus()          { return status; }
    public void setStatus(OrderStatus s)    { this.status = s; }
    public BigDecimal getTotal()            { return total; }
    public void setTotal(BigDecimal t)      { this.total = t; }
}

public class OrderService {
    public void submit(Order order) {
        BigDecimal total = order.getItems().stream()
            .map(LineItem::subtotal).reduce(BigDecimal.ZERO, BigDecimal::add);
        order.setTotal(total);
        order.setStatus(OrderStatus.SUBMITTED);
        repo.save(order);
    }
}

// elsewhere — a second entry point added a year later by another team
public class BulkImporter {
    public void importOrder(Order order) {
        order.setStatus(OrderStatus.SUBMITTED);   // mark it submitted
        repo.save(order);                          // ...and persist
    }
}

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

public class Order {
    private final List<LineItem> items = new ArrayList<>();
    private OrderStatus status = OrderStatus.DRAFT;
    private BigDecimal total = BigDecimal.ZERO;

    public void submit() {
        this.total = items.stream()
            .map(LineItem::subtotal).reduce(BigDecimal.ZERO, BigDecimal::add);
        if (total.signum() <= 0)
            throw new IllegalStateException("cannot submit an order with no value");
        this.status = OrderStatus.SUBMITTED;
    }
    // no public setStatus/setTotal — the only way to become SUBMITTED is submit()
}

Snippet 2 — The base class everything extends¶

// Java — every service in the app extends this
public abstract class BaseService {
    protected Logger log = LoggerFactory.getLogger(getClass());
    protected ObjectMapper json = new ObjectMapper();

    protected String toJson(Object o) {
        try { return json.writeValueAsString(o); }
        catch (Exception e) { throw new RuntimeException(e); }
    }
    protected boolean isBlank(String s) { return s == null || s.trim().isEmpty(); }
    protected Instant now() { return Instant.now(); }
}

public class UserService extends BaseService {
    public void register(String email) {
        if (isBlank(email)) throw new IllegalArgumentException("email required");
        log.info("registering {}", toJson(email));
        // ...
    }
}

public class PaymentService extends BaseService {
    public void charge(Money m) {
        log.info("charging at {}", now());
        // ...
    }
}

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

// utilities are just functions (or a small injected helper), not a superclass
public final class Json {
    public static String of(Object o) { /* ... */ }
}
public final class Strings {
    public static boolean isBlank(String s) { return s == null || s.isBlank(); }
}

public class UserService {                       // extends nothing
    private static final Logger log = LoggerFactory.getLogger(UserService.class);
    private final Clock clock;                   // injected — testable
    public UserService(Clock clock) { this.clock = clock; }
}

Snippet 3 — The constants everyone implements¶

// Java — shared constants for the protocol layer
public interface ProtocolConstants {
    int    DEFAULT_PORT     = 8080;
    int    MAX_PACKET_SIZE  = 65_535;
    String MAGIC_HEADER     = "X-PROTO-V2";
    byte   FRAME_START      = 0x02;
}

// dozens of classes do this to "get" the constants:
public class FrameDecoder implements ProtocolConstants {
    public Frame decode(byte[] buf) {
        if (buf.length > MAX_PACKET_SIZE) throw new FrameTooBigException();
        if (buf[0] != FRAME_START)        throw new BadFrameException();
        // ...
    }
}

public class TlsFrameDecoder extends FrameDecoder implements Serializable {
    // inherits ProtocolConstants through FrameDecoder — and now they're
    // part of TlsFrameDecoder's public API surface too
}

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

public final class Protocol {                    // a holder, not an interface
    private Protocol() {}
    public static final int    DEFAULT_PORT    = 8080;
    public static final int    MAX_PACKET_SIZE = 65_535;
    public static final byte   FRAME_START     = 0x02;
}

import static com.example.Protocol.MAX_PACKET_SIZE;   // static import where wanted

public class FrameDecoder {                      // implements nothing for constants
    public Frame decode(byte[] buf) {
        if (buf.length > MAX_PACKET_SIZE) throw new FrameTooBigException();
    }
}

Snippet 4 — The manager that just delegates¶

# Python — order cancellation flow
class CancellationManager:
    def __init__(self, order_repo, refund_service):
        self.order_repo = order_repo
        self.refund_service = refund_service

    def cancel(self, order_id):
        helper = CancellationHelper(self.order_repo, self.refund_service)
        return helper.do_cancel(order_id)

class CancellationHelper:
    def __init__(self, order_repo, refund_service):
        self.order_repo = order_repo
        self.refund_service = refund_service

    def do_cancel(self, order_id):
        order = self.order_repo.get(order_id)
        order.status = "CANCELLED"
        self.order_repo.save(order)
        self.refund_service.refund(order)
        return order

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

class CancellationService:
    def __init__(self, order_repo, refund_service):
        self.order_repo = order_repo
        self.refund_service = refund_service

    def cancel(self, order_id):
        order = self.order_repo.get(order_id)
        order.status = "CANCELLED"
        self.order_repo.save(order)
        self.refund_service.refund(order)
        return order

Snippet 5 — The event everyone can edit¶

// Go — a calendar event shared across a scheduling pipeline
type Event struct {
    Title     string
    Start     time.Time
    End       time.Time
    Attendees []string
}

func (s *Scheduler) Book(e *Event) error {
    if !e.End.After(e.Start) {
        return errors.New("end must be after start")
    }
    s.calendar[e.Start] = e          // store the pointer
    s.notify(e.Attendees)
    return nil
}

// far away, in a reminder worker that received the same *Event
func (w *ReminderWorker) prepare(e *Event) {
    // "normalize" the window for the reminder UI
    e.Start = e.Start.Add(-15 * time.Minute)   // mutates the shared event!
    e.End = e.End.Add(-15 * time.Minute)
    w.enqueue(e)
}

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

func (w *ReminderWorker) prepare(e Event) {       // take by value: a copy
    e.Start = e.Start.Add(-15 * time.Minute)      // mutates only the local copy
    e.End = e.End.Add(-15 * time.Minute)
    w.enqueue(&e)
}

// and have Book defend itself by storing a copy, not the caller's pointer:
func (s *Scheduler) Book(e Event) error {
    if !e.End.After(e.Start) { return errors.New("end must be after start") }
    stored := e                                   // own copy
    s.calendar[e.Start] = &stored
    s.notify(e.Attendees)
    return nil
}

Snippet 6 — The class full of statics¶

# Python — the "geometry engine" of a CAD-ish app
class GeometryEngine:
    @staticmethod
    def distance(a, b):
        return ((a[0] - b[0]) ** 2 + (a[1] - b[1]) ** 2) ** 0.5

    @staticmethod
    def midpoint(a, b):
        return ((a[0] + b[0]) / 2, (a[1] + b[1]) / 2)

    @staticmethod
    def translate(point, dx, dy):
        return (point[0] + dx, point[1] + dy)

    @staticmethod
    def area_of_triangle(a, b, c):
        return abs((a[0]*(b[1]-c[1]) + b[0]*(c[1]-a[1]) + c[0]*(a[1]-b[1])) / 2)

# usage everywhere:
d = GeometryEngine.distance(p1, p2)
m = GeometryEngine.midpoint(p1, p2)

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

# geometry.py
def distance(a, b): ...
def midpoint(a, b): ...

from geometry import distance, midpoint
d = distance(p1, p2)

@dataclass(frozen=True)
class Point:
    x: float
    y: float
    def distance_to(self, other): return math.hypot(self.x - other.x, self.y - other.y)
    def midpoint(self, other):    return Point((self.x+other.x)/2, (self.y+other.y)/2)

Snippet 7 — The lifecycle hook that must call super¶

// Java — a framework base class for request handlers
public abstract class RequestHandler {
    private final List<AutoCloseable> opened = new ArrayList<>();

    // subclasses override this to open per-request resources
    public void onRequest(Request req) {
        // base sets up tracing + a span we MUST close in onComplete
        Tracer.startSpan(req.id());
        opened.add(Tracer.currentSpan());
    }

    public void onComplete(Request req) {
        // base closes everything opened during the request
        for (AutoCloseable c : opened) { try { c.close(); } catch (Exception ignored) {} }
        opened.clear();
    }
}

public class CheckoutHandler extends RequestHandler {
    private Connection conn;

    @Override
    public void onRequest(Request req) {
        // (forgot to call super.onRequest(req))
        this.conn = pool.acquire();
        // ... handle checkout ...
    }

    @Override
    public void onComplete(Request req) {
        super.onComplete(req);
        if (conn != null) pool.release(conn);
    }
}

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

public abstract class RequestHandler {
    private final List<AutoCloseable> opened = new ArrayList<>();

    public final void handle(Request req) {        // final: subclasses can't break the flow
        Tracer.startSpan(req.id());
        opened.add(Tracer.currentSpan());
        try {
            doHandle(req);                          // the only thing subclasses write
        } finally {
            for (AutoCloseable c : opened) { try { c.close(); } catch (Exception ignored) {} }
            opened.clear();
        }
    }

    protected abstract void doHandle(Request req);  // the hook, no super to call
}

public class CheckoutHandler extends RequestHandler {
    @Override protected void doHandle(Request req) {
        try (Connection conn = pool.acquire()) { /* ... handle checkout ... */ }
    }
}

Snippet 8 — The context bag¶

# Python — request context threaded through a pipeline
def handle(request):
    ctx = {
        "user_id": request.user_id,
        "tenant": request.tenant,
        "locale": request.headers.get("Accept-Language", "en"),
    }
    enrich(ctx)
    return render(ctx)

def enrich(ctx):
    user = db.get_user(ctx["user_id"])
    ctx["user_name"] = user.name
    ctx["is_admin"] = user.role == "admin"
    # note: stored under "tier", read elsewhere as "user_tier"
    ctx["tier"] = user.tier

def render(ctx):
    greeting = f"Hello {ctx['user_name']}"
    if ctx["is_admin"]:
        greeting += " (admin)"
    # pricing depends on tier
    discount = TIER_DISCOUNTS[ctx["user_tier"]]      # KeyError waiting to happen
    return template.render(greeting=greeting, discount=discount, locale=ctx["locale"])

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

@dataclass
class RequestContext:
    user_id: int
    tenant: str
    locale: str
    user_name: str | None = None
    is_admin: bool = False
    tier: str | None = None

def enrich(ctx: RequestContext) -> None:
    user = db.get_user(ctx.user_id)
    ctx.user_name = user.name
    ctx.is_admin = user.role == "admin"
    ctx.tier = user.tier

def render(ctx: RequestContext):
    discount = TIER_DISCOUNTS[ctx.tier]   # ctx.user_tier wouldn't even type-check

Snippet 9 — The transfer with a boolean¶

// Go — money movement between accounts
func Transfer(from, to *Account, amount Money, notify bool) error {
    if from.Balance < amount {
        return errors.New("insufficient funds")
    }
    from.Balance -= amount
    to.Balance += amount
    ledger.Record(from, to, amount)
    if notify {
        mailer.Send(from.Owner, "debit", amount)
        mailer.Send(to.Owner, "credit", amount)
    }
    return nil
}

// two call sites:
func handleUserTransfer(req Req) error {
    return Transfer(req.From, req.To, req.Amount, false)   // user-initiated
}

func reconcileNightly(a, b *Account, m Money) error {
    return Transfer(a, b, m, true)                          // internal sweep
}

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

// two methods, each named for what it does:
func Transfer(from, to *Account, amount Money) error { /* moves money, no email */ }

func TransferAndNotify(from, to *Account, amount Money) error {
    if err := Transfer(from, to, amount); err != nil { return err }
    mailer.Send(from.Owner, "debit", amount)
    mailer.Send(to.Owner, "credit", amount)
    return nil
}

func handleUserTransfer(req Req) error { return TransferAndNotify(req.From, req.To, req.Amount) }
func reconcileNightly(a, b *Account, m Money) error { return Transfer(a, b, m) }

Snippet 10 — The notification constructors¶

// Java — a Notification value object, grown over many features
public class Notification {
    private final String recipient;
    private final String subject;
    private final String body;
    private final boolean html;
    private final int priority;
    private final String replyTo;
    private final List<String> cc;
    private final Instant scheduledAt;

    public Notification(String recipient, String subject, String body) {
        this(recipient, subject, body, false);
    }
    public Notification(String recipient, String subject, String body, boolean html) {
        this(recipient, subject, body, html, 0);
    }
    public Notification(String recipient, String subject, String body,
                        boolean html, int priority) {
        this(recipient, subject, body, html, priority, null);
    }
    public Notification(String recipient, String subject, String body,
                        boolean html, int priority, String replyTo) {
        this(recipient, subject, body, html, priority, replyTo, List.of(), null);
    }
    public Notification(String recipient, String subject, String body, boolean html,
                        int priority, String replyTo, List<String> cc, Instant scheduledAt) {
        this.recipient = recipient; this.subject = subject; this.body = body;
        this.html = html; this.priority = priority; this.replyTo = replyTo;
        this.cc = cc; this.scheduledAt = scheduledAt;
    }
}

// a call site:
new Notification("a@x.com", "Hi", "<b>hello</b>", true, 5, null, List.of(), someTime);

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

Notification n = Notification.builder()
    .recipient("a@x.com")
    .subject("Hi")
    .htmlBody("<b>hello</b>")     // method name encodes the "html" choice — no bare bool
    .priority(5)
    .scheduledAt(someTime)
    .build();                     // build() can validate invariants in one place

Snippet 11 — The base class that added a field¶

# Python — a framework base collection, used by many subclasses
class CountingList:
    def __init__(self):
        self._items = []
        self._add_count = 0          # how many times add() was called

    def add(self, item):
        self._items.append(item)
        self._add_count += 1

    def add_all(self, items):
        for it in items:
            self.add(item=it)        # delegates to add() so the count stays correct

    def add_count(self):
        return self._add_count

# a subclass written by another team, against the ORIGINAL base
class DedupeList(CountingList):
    def add(self, item):
        if item not in self._items:
            super().add(item)

    def add_all(self, items):
        # optimization: bulk-insert unique items directly, skip per-item add()
        unique = [i for i in items if i not in self._items]
        self._items.extend(unique)   # bypasses add(), so _add_count is now wrong

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

# Composition removes the fragility entirely:
class DedupeList:
    def __init__(self):
        self._inner = CountingList()      # has-a, not is-a
        self._seen = set()

    def add(self, item):
        if item not in self._seen:
            self._seen.add(item)
            self._inner.add(item)         # always goes through the public API

    def add_all(self, items):
        for it in items:
            self.add(it)                  # we control our own dispatch; no hidden self-use

    def add_count(self):
        return self._inner.add_count()

Snippet 12 — The wallet that trusts its caller¶

# Python — an in-game wallet
class Wallet:
    def __init__(self):
        self.balance = 0
        self.transactions = []

class WalletService:
    def spend(self, wallet, amount):
        if wallet.balance >= amount:
            wallet.balance -= amount
            wallet.transactions.append(("spend", amount))
            return True
        return False

# a feature added later — "gift" coins between players
def gift(sender_wallet, receiver_wallet, amount):
    sender_wallet.balance -= amount             # no check!
    receiver_wallet.balance += amount

# and a leaderboard module that just reads... or does it
def recompute_rank(wallet):
    wallet.transactions.sort(key=lambda t: t[1])   # sorts the LIVE list in place
    return derive_rank(wallet.transactions)

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

class Wallet:
    def __init__(self):
        self._balance = 0
        self._transactions = []

    @property
    def balance(self): return self._balance

    def spend(self, amount):
        if amount <= 0 or amount > self._balance:
            raise ValueError("invalid spend")          # the rule lives here, always
        self._balance -= amount
        self._transactions.append(("spend", amount))

    def gift_to(self, other, amount):
        self.spend(amount)                              # reuses the SAME guarded path
        other.receive(amount)

    def receive(self, amount):
        self._balance += amount
        self._transactions.append(("receive", amount))

    def transactions(self):
        return list(self._transactions)                # defensive copy: callers can't sort the live list

Snippet 13 — The audited repository¶

# Python — a base repository giving every entity an audit trail
class AuditedRepository:
    def save(self, entity):
        self._write_audit("save", entity)    # MUST run before persistence
        self._persist(entity)

    def delete(self, entity):
        self._write_audit("delete", entity)
        self._remove(entity)

    def _write_audit(self, action, entity):
        audit_log.append(action, entity.id, now())

class OrderRepository(AuditedRepository):
    def save(self, order):
        # adds order-specific validation, then persists
        if not order.line_items:
            raise ValueError("empty order")
        self._persist(order)                  # overrode save(); calls _persist directly

    def _persist(self, order):
        db.upsert("orders", order)
    def _remove(self, order):
        db.delete("orders", order.id)

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

class AuditedRepository:
    def save(self, entity):                # NOT meant to be overridden
        self._validate(entity)             # hook
        self._write_audit("save", entity)  # invariant: always audited
        self._persist(entity)              # hook

    def delete(self, entity):
        self._write_audit("delete", entity)
        self._remove(entity)

    # hooks subclasses fill in — no super() to remember
    def _validate(self, entity): pass
    def _persist(self, entity):  raise NotImplementedError
    def _remove(self, entity):   raise NotImplementedError

class OrderRepository(AuditedRepository):
    def _validate(self, order):
        if not order.line_items:
            raise ValueError("empty order")
    def _persist(self, order): db.upsert("orders", order)
    def _remove(self, order):  db.delete("orders", order.id)

Snippet 14 — The DTO with no behavior¶

// Go — the wire type for a public REST API
type UserResponse struct {
    ID        string    `json:"id"`
    Email     string    `json:"email"`
    CreatedAt time.Time `json:"created_at"`
    Plan      string    `json:"plan"`
}

func toResponse(u domain.User) UserResponse {
    return UserResponse{
        ID:        u.ID().String(),
        Email:     u.Email(),
        CreatedAt: u.CreatedAt(),
        Plan:      string(u.Plan()),
    }
}

func GetUser(w http.ResponseWriter, r *http.Request) {
    u, err := svc.Find(mux.Vars(r)["id"])
    if err != nil { http.Error(w, err.Error(), 404); return }
    json.NewEncoder(w).Encode(toResponse(u))
}

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

Snippet 15 — The private helper with a flag¶

# Python — inside a single module; _format is private (leading underscore)
class InvoiceFormatter:
    def render(self, invoice):
        head = self._format(invoice.title, upper=True)
        lines = [self._format(item.name) for item in invoice.items]
        return head + "\n" + "\n".join(lines)

    def _format(self, text, upper=False):
        text = text.strip()
        return text.upper() if upper else text

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

Summary — patterns of spotting¶

You don't spot OO-misuse anti-patterns by recognizing a single bad line — you spot them by where the behavior lives, where the encapsulation leaks, and what the inheritance contract silently assumes. The repeatable moves from these fifteen snippets:

• Ask "where does the invariant live?" If the rule that protects an object's state sits in a service or helper rather than on the object, it's an Anemic Domain Model, and the bug arrives the day a second code path forgets the rule (Snippets 1, 12). The cure is Tell, Don't Ask: move behavior to the data.
• Follow shared pointers/references across modules. Public mutable fields handed out by reference are an Object Orgy; the corruption happens "at a distance" where no single function looks wrong (Snippets 5, 12). Copy at boundaries, return defensive copies, or make the type immutable.
• Distrust "you must call super" contracts. Any base class that requires subclasses to call super.method() or route through a specific method is Call Super / Fragile Base Class, and the bug is the forgotten call or the bypassed base step (Snippets 7, 11, 13). The cure is Template Method: make the flow final, expose a separate hook subclasses can't forget.
• Treat Map<String,Object> / dict[str,Any] / Bundle as a red flag. A Magic Container moves the schema out of the type system and into programmers' memory; a typo'd or mismatched key becomes a runtime KeyError/NPE on a path the compiler can't check (Snippet 8). Define a real typed struct.
• Count boolean parameters — then check the call sites. A behavior-flipping Flag Argument reliably gets transposed, and the call site won't show it (Snippet 9). Split into intention-revealing methods. But weigh by cost: a keyword flag on a tiny private helper is fine (Snippet 15).
• Watch constructor overload chains and empty utility classes. A growing N-arg overload set is a Telescoping Constructor → use a Builder or named args (Snippet 10). A class that's never instantiated and holds only statics is Functional Decomposition → use free functions or find the real object (Snippet 6). Inheriting from a grab-bag of helpers is BaseBean (Snippet 2); implements used only to import constants is a Constant Interface (Snippet 3); a stateless pass-through class is a Poltergeist (Snippet 4) — inline it.
• Resist false positives. A behavior-free struct at a serialization boundary is a justified DTO, not an anemic domain model (Snippet 14). Diagnose by role and cost, not by shape — the same code is an anti-pattern in one context and correct design in another.

The meta-lesson: OO misuse isn't only aesthetic. An anemic order shipped with total == 0; an object orgy corrupted a booking 15 minutes early; a forgotten super call blew a hole in tracing; a fragile base class lost the add-count; a mismatched magic-container key KeyError-ed on the pricing path; a transposed flag emailed the wrong people. When the responsibilities are allocated wrongly or the encapsulation leaks, look hard — the latent functional bug is usually hiding in exactly the path the misuse made impossible to see.

Related Topics¶

• junior.md — what each of the eleven OO-misuse shapes looks like and why it's bad.
• middle.md — when these creep in and the small countermove that reverses them.
• senior.md — detecting them in review and migrating inheritance hierarchies at scale.
• professional.md — testability, performance, and observability implications.
• tasks.md — design exercises that build the same muscles from the writing side.
• optimize.md — flawed OO designs to redesign end-to-end.
• interview.md — Q&A across all levels.
• Coupling & State and Abstraction Failures — the sibling find-bug files.
• Clean Code → Objects and Data Structures — Tell-Don't-Ask, the cure for anemic models.
• Clean Code → Classes — SRP and ISP behind several of these.
• Design Patterns → Behavioral — Template Method, the structural cure for Call Super.
• Design Patterns → Builder — the cure for Telescoping Constructor.
• Refactoring → Code Smells — the smell-level view of the same problems.