OO Misuse Anti-Patterns — Interview Q&A¶

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

A bank of 60+ interview questions and answers spanning recognition, design trade-offs, root-cause analysis, and runtime/dispatch/GC implications. Each answer models the reasoning a strong candidate gives — including the trade-offs and the cases where the "anti-pattern" is actually the right call. Use the <details> toggles to self-quiz: read the question, answer out loud, then expand.

Table of Contents¶

1. Fundamentals / Junior
2. Intermediate / Middle
3. Senior — Design Forces, Migration & Boundaries
4. Professional / Deep — Dispatch, Memory, GC, Toolchain
5. Code-Reading — Name the Anti-Pattern
6. Curveballs
7. Rapid-Fire / One-Liners
8. How to Talk About Anti-Patterns in Interviews
9. Summary
10. Related Topics

Fundamentals / Junior¶

Definitions, recognition, and the "why is it bad" reasoning.

Q1. Name the eleven OO-misuse anti-patterns and give a one-line symptom for each.

Q2. What is the Anemic Domain Model, and why did Fowler call it an anti-pattern rather than a style?

Q3. What's the difference between a code smell and an anti-pattern in this category?

Q4. Why is a flag argument like save(true) bad? Show the fix.

// before
file.save(true);  file.save(false);
// after
file.saveOverwriting();  file.saveIfAbsent();

Q5. What is a Telescoping Constructor and what does the Builder pattern fix about it?

Q6. What is Object Orgy, and how is it different from just "having public fields"?

Q7. What is the Constant Interface anti-pattern (Java), and what should you use instead?

Q8. What is a Poltergeist?

Q9. What is Functional Decomposition as an OO anti-pattern?

Q10. What is the Call Super anti-pattern?

Q11. What is a Magic Container and why is it dangerous?

Q12. What is the Fragile Base Class problem?

Q13. Why is "it works and the tests pass" not a defense for these designs?

Q14. Encapsulation in one sentence — and which anti-patterns here violate it most directly?

Intermediate / Middle¶

When each design emerges, what to do instead, and the trade-offs.

Q15. Nobody decides "I'll write an anemic model." How does it actually happen?

Q16. When is a flag argument actually acceptable?

Q17. Composition over inheritance — does that mean always composition?

Q18. How do you tell BaseBean inheritance from legitimate inheritance in review?

Q19. When is the Builder pattern overkill?

Q20. What do you do instead of a Magic Container when the shape really is dynamic?

Q21. How does the Template Method pattern fix Call Super, concretely?

// Call Super (fragile): subclass MUST remember super.onInit()
abstract class Widget { void onInit() { registerMetrics(); } }
class MyWidget extends Widget {
    @Override void onInit() { super.onInit(); /* if forgotten, metrics break */ }
}

// Template Method (safe): base controls flow, hook is separate & abstract
abstract class Widget {
    final void init() { registerMetrics(); doInit(); }  // base guarantees order
    protected abstract void doInit();                     // subclass can't skip setup
}
class MyWidget extends Widget { protected void doInit() { /* just my part */ } }

Q22. An anemic model has all logic in services. What's the migration toward a richer model?

Q23. How do you detect Object Orgy in a Go codebase specifically?

Q24. Diagnose and fix this Python class.

class Order:
    def __init__(self):
        self.items = []
        self.total = 0.0
        self.status = "NEW"

class OrderService:
    def add_item(self, order, item):
        order.items.append(item)
        order.total += item.price
    def pay(self, order):
        if order.status != "NEW":
            raise ValueError("bad state")
        order.status = "PAID"

class Order:
    def __init__(self):
        self._items = []
        self._total = 0.0
        self._status = "NEW"

    def add_item(self, item):
        self._items.append(item)
        self._total += item.price

    def pay(self):
        if self._status != "NEW":
            raise ValueError("bad state")
        self._status = "PAID"

    @property
    def total(self): return self._total

Q25. Diagnose this Java constructor set. What's the fix and the trade-off?

public Report(String title) { this(title, "A4"); }
public Report(String title, String size) { this(title, size, false); }
public Report(String title, String size, boolean landscape) { this(title, size, landscape, null); }
public Report(String title, String size, boolean landscape, String watermark) { /* ... */ }

Report r = Report.builder().title("Q3").size("A3").landscape().watermark("DRAFT").build();

Q26. Why is a Map<String, Object> returned from a public API worse than one used internally?

Q27. When does extracting a Poltergeist actually improve things vs. just removing a useful seam?

Q28. A junior wraps every function in a one-method class "to be object-oriented." How do you coach them?

Senior — Design Forces, Migration & Boundaries¶

Large-system design, organizational root causes, and when the "anti-pattern" is the right call.

Q29. Is an Anemic Domain Model always wrong?

Q30. What organizational and tooling forces breed these anti-patterns?

Q31. How do you migrate a large hierarchy off a Fragile Base Class safely?

Q32. Where is the right place to draw the line between "rich domain object" and "service"?

Q33. A team has a BaseController everything extends to get getCurrentUser(), log(), db(). How do you unwind it at scale?

Q34. When should you not refactor one of these anti-patterns?

Q35. How do you stop these from re-appearing — beyond fixing the instance?

Q36. Constant Interface vs. enum vs. static-import constants — how do you choose?

Professional / Deep — Dispatch, Memory, GC, Toolchain¶

Runtime, memory, dispatch, and tooling implications of these designs.

Q37. Why can a Map<String, Object> hurt performance, not just maintainability?

Q38. Does the Anemic vs. rich choice have any runtime cost, or is it purely design?

Q39. How does deep inheritance (BaseBean / Fragile Base Class) affect method dispatch?

Q40. How can these patterns create memory leaks / retention problems in GC'd runtimes?

Q41. What's the toolchain/build impact of Constant Interfaces and fat base classes?

Q42. What tools would you use to quantify these anti-patterns in a real codebase?

Code-Reading — Name the Anti-Pattern¶

You're shown a snippet; identify the anti-pattern(s) and state the fix.

Q43. Which anti-pattern, and what's the fix?

public interface AppConstants {
    int MAX_RETRIES = 3;
    String API_PREFIX = "/v1";
    long TIMEOUT_MS = 5000;
}
public class HttpClient implements AppConstants { /* uses MAX_RETRIES, TIMEOUT_MS */ }

final class AppConstants { private AppConstants() {}
    static final int MAX_RETRIES = 3; static final long TIMEOUT_MS = 5000; }
// in HttpClient:  import static AppConstants.*;

Q44. Which anti-pattern, and what's the fix?

type Config struct {
    Settings map[string]interface{}
}
func (c *Config) Port() int { return c.Settings["port"].(int) }   // panics on typo or wrong type

type Config struct {
    Port    int
    Timeout time.Duration
}
// decode JSON/YAML into Config at startup; the rest of the app uses typed fields.

Q45. Which anti-pattern, and what's the fix?

class AuditLog {
    void onEvent(Event e) {
        write(e);
        afterWrite();   // subclasses MUST override and call super.afterWrite()
    }
    protected void afterWrite() { flush(); }
}

class AuditLog {
    final void onEvent(Event e) { write(e); afterWrite(); flush(); } // base guarantees flush
    protected void afterWrite() {}   // empty hook; subclasses add their part, no super needed
}

Q46. Which anti-pattern, and what's the fix?

class InvoiceManager:
    def __init__(self, repo): self.repo = repo
    def generate(self, order_id):
        order = self.repo.get(order_id)
        return Invoice(order).render()

Q47. Which anti-pattern(s), and what's the fix?

public class User {
    public String name;
    public List<Role> roles = new ArrayList<>();
    public int loginAttempts;
}
// elsewhere, scattered across the codebase:
user.loginAttempts++;
user.roles.add(adminRole);
if (user.loginAttempts > 3) { /* lock */ }

public class User {
    private int loginAttempts;
    private final List<Role> roles = new ArrayList<>();
    public void recordFailedLogin() { if (++loginAttempts > 3) lock(); }
    public List<Role> roles() { return Collections.unmodifiableList(roles); }
    public void grant(Role r) { roles.add(r); }
}

Q48. Which anti-pattern, and what's the fix?

def notify(user, email=True, sms=False, push=False, urgent=False):
    msg = build(user, urgent)
    if email: send_email(user, msg)
    if sms:   send_sms(user, msg)
    if push:  send_push(user, msg)

class Channel(Enum): EMAIL = auto(); SMS = auto(); PUSH = auto()

def notify(user, channels: set[Channel], urgent=False):
    msg = build(user, urgent)
    senders = {Channel.EMAIL: send_email, Channel.SMS: send_sms, Channel.PUSH: send_push}
    for ch in channels: senders[ch](user, msg)

Q49. Which anti-pattern, and what's the fix?

type Calculator struct{}
func (Calculator) Add(a, b int) int { return a + b }
func (Calculator) Mul(a, b int) int { return a * b }
// callers: Calculator{}.Add(2, 3)

func Add(a, b int) int { return a + b }
func Mul(a, b int) int { return a * b }
// callers: Add(2, 3)

Q50. This snippet shows three anti-patterns at once — name them.

class ReportJob extends BaseJob {           // BaseJob gives log(), metrics(), config()
    @Override void run() {
        super.run();                        // forget this and scheduling breaks
        var data = new HashMap<String,Object>();
        data.put("rows", query());
        data.put("fmt", "pdf");
        export(data);
    }
}

Curveballs¶

The questions designed to catch glib answers.

Q51. "OO means everything should be an object with behavior." Agree?

Q52. Composition over inheritance — so inheritance is always wrong?

Q53. When is a flag argument acceptable?

Q54. When is the Builder pattern overkill?

Q55. Why can a Map<String, Object> hurt performance?

Q56. Isn't an anemic model just fine for a simple CRUD app?

Q57. A teammate says "getters and setters are encapsulation." Are they?

Q58. Is a single one-method class always Functional Decomposition?

Rapid-Fire / One-Liners¶

Crisp answers; what an interviewer wants in one or two sentences.

Q59. One-line cure for each of the eleven?

Q60. The phrase that signals an Anemic Domain Model?

Q61. The phrase that signals BaseBean?

Q62. Fastest tell of a Telescoping Constructor at a call site?

Q63. is-a vs has-a — which anti-patterns confuse them?

Q64. One sentence: what's the root habit behind most OO-misuse?

Q65. Encapsulation in one sentence, and which anti-pattern most directly violates it?

Q66. Builder vs named arguments — one-line rule?

How to Talk About Anti-Patterns in Interviews¶

A few habits separate a strong answer from a textbook recital:

• Lead with the cost, not the label. Don't just say "that's an Anemic Domain Model." Say why it hurts — "the overdraw invariant lives in the service, so any new call site can violate it, and the rule gets copy-pasted." Interviewers want the reasoning, not the vocabulary.
• Name the case where it's not an anti-pattern. Senior signal is the nuance: anemic is correct for DTOs and read models; inheritance is right for genuine substitutable types; a flag is fine when it's data, not a behavior switch; a one-method class is fine as a strategy. "It depends, and here's on what" beats absolutism.
• Match the cure to the language. Builder in Java, named arguments in Kotlin/Python; free functions in Go for Functional Decomposition; enum for closed constant sets. Picking the right tool per language reads as real experience.
• Show you'd migrate safely. Mention characterization tests, incremental green-to-green steps, separating structural from behavioral commits, and Strangler-style hierarchy unwinding. This proves production scars, not just reading.
• Distinguish "I'd fix this" from "I'd fix it now." Knowing when not to refactor (stable code, boundaries where anemic is right, no test net) is a stronger signal than reflexively "fixing" everything.
• Go deep when invited. Megamorphic dispatch and inline-cache limits, boxing and cache locality of Magic Containers, constant-inlining recompilation magnets, GC retention from leaked internals — these show depth past the maintainability story.
• Avoid purism. "Everything must be an object with behavior," "never use inheritance," "always use a builder," "getters are encapsulation" are juniorisms. Calibrate to invariants, substitutability, parameter count, and present-day value.

Summary¶

• The eleven OO-misuse anti-patterns all take an OO mechanism and use it for the wrong thing: Anemic Domain Model and Object Orgy abandon encapsulation; BaseBean, Call Super, and Fragile Base Class abuse or over-rely on inheritance; Constant Interface and Functional Decomposition misuse the type/class system; Magic Container bypasses the type system; Flag Arguments and Telescoping Constructor are method/constructor-shape failures; Poltergeist is needless object indirection.
• Recognition is the junior bar; the middle bar is knowing when each emerges and the language-appropriate countermove (Builder vs named args, Template Method, typed structs, injected utilities); the senior bar is safe migration at scale, root-cause forces, and where the "anti-pattern" is actually correct; the professional bar is the dispatch, memory, GC, and toolchain consequences (megamorphic call sites, boxing, retention, recompilation magnets).
• The strongest answers lead with cost and reasoning, name the case where it's not an anti-pattern (DTOs, substitutable types, data-flags, strategies), match the cure to the language, and refactor safely and incrementally.
• The recurring curveball insight: judge by invariants, substitutability, and present-day value — not by "everything must be an object," "never inherit," or "always use a builder."

Related Topics¶

• junior.md — recognize each shape and avoid creating it.
• middle.md — when each emerges and the everyday countermoves.
• senior.md — migration at scale, root causes, and when the anemic/inheritance choice is correct.
• professional.md — dispatch, memory, GC, and toolchain implications.
• tasks.md · find-bug.md · optimize.md — practice the diagnosis and redesign.
• Design Anti-Patterns overview — how OO Misuse relates to Coupling & State and Abstraction Failures.
• Clean Code → Objects and Data Structures — Tell-Don't-Ask, the Anemic Model cure.
• Clean Code → Classes — cohesion, SRP, and the Interface Segregation Principle.
• Clean Code → Immutability — read-only views, the Object Orgy cure.
• Design Patterns → Creational → Builder — the Telescoping Constructor cure.
• Design Patterns → Behavioral — Template Method, the Call Super cure.
• Refactoring → Code Smells — Data Class, Long Parameter List, the smell-level view.