OO Misuse Anti-Patterns — Refactoring Practice¶

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

These are not "spot the smell" puzzles — find-bug.md does that. Here the code is structurally bad but already working, and your job is to transform it into clean OO without changing behavior. The skill on display is the process, not the destination:

1. Pin behavior first. Write a characterization test — a test that records what the code does now, bugs included. With OO you usually pin behavior at the public seam (the class's public methods, the function's return + side effects), because the refactor will move logic behind that seam.
2. Take small, reversible steps. One named refactoring at a time (Move Method, Replace Constructor with Builder, Replace Inheritance with Delegation, …), tests green after each, commit.
3. Separate structural from behavioral commits. A refactor must preserve behavior; if a test goes red, the last step is the culprit — revert it.

Each worked solution names the canonical refactoring moves (from Fowler's Refactoring and Feathers' Working Effectively with Legacy Code) so you build the vocabulary, not just the instinct.

How to use this file: read the "Before" code, write down the move sequence yourself before expanding the solution, then compare. The gap between your plan and the worked plan is where the learning is.

Table of Contents¶

Exercise 1 — Replace the flag argument¶

Anti-pattern: Flag Arguments. Goal: remove the boolean that flips behavior so each behavior has its own named entry point. Constraints: preserve both current behaviors; callers may be updated.

// Before — one boolean selects between two genuinely different behaviors.
public Money convert(Money amount, Currency to, boolean useLiveRate) {
    Rate rate = useLiveRate
        ? rateService.fetchLive(amount.currency(), to)   // network call, may be stale-tolerant
        : rateService.cachedDaily(amount.currency(), to); // in-memory, fixed for the day
    return new Money(amount.value().multiply(rate.value()), to);
}

// every call site has to remember what `true` means:
convert(price, EUR, true);
convert(price, EUR, false);

// After — the method name carries the intent; no boolean to misread.
public Money convertLive(Money amount, Currency to) {
    return apply(amount, to, rateService.fetchLive(amount.currency(), to));
}

public Money convertDaily(Money amount, Currency to) {
    return apply(amount, to, rateService.cachedDaily(amount.currency(), to));
}

private Money apply(Money amount, Currency to, Rate rate) {
    return new Money(amount.value().multiply(rate.value()), to);
}

// call sites are now self-documenting:
convertLive(price, EUR);
convertDaily(price, EUR);

Exercise 2 — Tame the telescoping constructor¶

Anti-pattern: Telescoping Constructor. Goal: replace the overload chain with a Builder so construction is readable and optional fields are explicit. Constraints: the resulting object must be identical for equivalent inputs; keep the type immutable.

// Before — five overloads, each delegating to the next; the 7-arg one is unreadable.
public final class Pizza {
    private final Size size;
    private final Crust crust;
    private final boolean cheese, pepperoni, mushroom;
    private final int slices;

    public Pizza(Size size) { this(size, Crust.THIN); }
    public Pizza(Size size, Crust crust) { this(size, crust, true); }
    public Pizza(Size size, Crust crust, boolean cheese) { this(size, crust, cheese, false); }
    public Pizza(Size size, Crust crust, boolean cheese, boolean pepperoni) {
        this(size, crust, cheese, pepperoni, false);
    }
    public Pizza(Size size, Crust crust, boolean cheese, boolean pepperoni, boolean mushroom) {
        this.size = size; this.crust = crust; this.cheese = cheese;
        this.pepperoni = pepperoni; this.mushroom = mushroom;
        this.slices = size == Size.LARGE ? 8 : 6;
    }
}

// call site — what is the third 'true'? what is 'false, true'?
new Pizza(Size.LARGE, Crust.STUFFED, true, false, true);

// After — required arg in the builder ctor; optionals are named and defaulted.
public final class Pizza {
    private final Size size;
    private final Crust crust;
    private final boolean cheese, pepperoni, mushroom;
    private final int slices;

    private Pizza(Builder b) {
        this.size = b.size; this.crust = b.crust; this.cheese = b.cheese;
        this.pepperoni = b.pepperoni; this.mushroom = b.mushroom;
        this.slices = size == Size.LARGE ? 8 : 6;   // same derivation as before
    }

    public static Builder of(Size size) { return new Builder(size); }

    public static final class Builder {
        private final Size size;                 // required
        private Crust crust = Crust.THIN;        // defaults match the old overloads
        private boolean cheese = true;
        private boolean pepperoni = false;
        private boolean mushroom = false;

        private Builder(Size size) { this.size = size; }
        public Builder crust(Crust c)      { this.crust = c; return this; }
        public Builder cheese(boolean v)   { this.cheese = v; return this; }
        public Builder pepperoni(boolean v){ this.pepperoni = v; return this; }
        public Builder mushroom(boolean v) { this.mushroom = v; return this; }
        public Pizza build()               { return new Pizza(this); }
    }
}

// call site — every value is labelled; order no longer matters.
Pizza p = Pizza.of(Size.LARGE).crust(Crust.STUFFED).pepperoni(true).mushroom(true).build();

Exercise 3 — Give the Magic Container a type¶

Anti-pattern: Magic Container. Goal: replace a stringly-typed map[string]any passed across the codebase with a real type whose fields the compiler checks. Constraints: same computed result; the conversion must surface, not hide, any missing-key assumptions.

// Before — a bag of any-typed values; keys are undocumented and unchecked.
func BuildInvoice(data map[string]any) (string, error) {
    customer := data["customer"].(string)          // panics if absent or wrong type
    amount := data["amount"].(float64)
    currency := data["currency"].(string)
    taxable, _ := data["taxable"].(bool)            // silently false if missing

    tax := 0.0
    if taxable {
        tax = amount * 0.2
    }
    total := amount + tax
    return fmt.Sprintf("%s owes %.2f %s", customer, total, currency), nil
}

// call site — nothing stops you misspelling "ammount" or omitting "currency".
BuildInvoice(map[string]any{"customer": "Acme", "amount": 100.0, "currency": "USD", "taxable": true})

// After — fields are named, typed, and checked at compile time.
type Invoice struct {
    Customer string
    Amount   float64
    Currency string
    Taxable  bool
}

func BuildInvoice(inv Invoice) string {
    tax := 0.0
    if inv.Taxable {
        tax = inv.Amount * 0.2
    }
    total := inv.Amount + tax
    return fmt.Sprintf("%s owes %.2f %s", inv.Customer, total, inv.Currency)
}

// call site — the compiler rejects a misspelled or missing field.
BuildInvoice(Invoice{Customer: "Acme", Amount: 100.0, Currency: "USD", Taxable: true})

Exercise 4 — Enrich the Anemic Domain Model¶

Anti-pattern: Anemic Domain Model. Goal: move behavior from a procedural "service" into the data object it operates on, applying Tell, Don't Ask. Constraints: preserve the externally observable results; the service's public method may delegate but must keep working.

# Before — Account is a bag of getters/setters; all logic lives in the service.
class Account:
    def __init__(self, balance, frozen=False):
        self._balance = balance
        self._frozen = frozen
    def get_balance(self): return self._balance
    def set_balance(self, v): self._balance = v
    def is_frozen(self): return self._frozen

class AccountService:
    def withdraw(self, account, amount):
        if account.is_frozen():
            raise ValueError("account frozen")
        if amount <= 0:
            raise ValueError("amount must be positive")
        if amount > account.get_balance():            # ASK
            raise ValueError("insufficient funds")
        account.set_balance(account.get_balance() - amount)  # then mutate from outside
        return account.get_balance()

# After — the object owns its invariants; the service just delegates.
class Account:
    def __init__(self, balance, frozen=False):
        self._balance = balance
        self._frozen = frozen

    @property
    def balance(self):            # read-only view for display; no setter
        return self._balance

    def withdraw(self, amount):
        if self._frozen:
            raise ValueError("account frozen")
        if amount <= 0:
            raise ValueError("amount must be positive")
        if amount > self._balance:
            raise ValueError("insufficient funds")
        self._balance -= amount
        return self._balance

class AccountService:
    def withdraw(self, account, amount):
        return account.withdraw(amount)   # thin coordinator; may add logging/tx later

Exercise 5 — Inline the Poltergeist¶

Anti-pattern: Poltergeist. Goal: remove a short-lived object that exists only to forward a call, contributing no state of its own. Constraints: preserve the final stored result; no behavior change.

// Before — ReportStarter holds nothing; it appears, forwards one call, vanishes.
type ReportStarter struct {
    generator *ReportGenerator
}

func NewReportStarter(g *ReportGenerator) *ReportStarter {
    return &ReportStarter{generator: g}
}

func (s *ReportStarter) Start(month string) Report {
    return s.generator.Generate(month)   // pure pass-through, no added logic
}

// caller — three lines to do one thing.
func RunMonthly(g *ReportGenerator, month string) Report {
    starter := NewReportStarter(g)
    return starter.Start(month)
}

// After — the intermediary is gone; the caller talks to the real worker.
func RunMonthly(g *ReportGenerator, month string) Report {
    return g.Generate(month)
}
// ReportStarter, NewReportStarter, Start: deleted (no state, no callers).

Exercise 6 — Tighten the Object Orgy¶

Anti-pattern: Object Orgy. Goal: restore encapsulation to a class whose internals are public and freely mutated from outside. Constraints: preserve the computed totals; callers that read may keep working via accessors.

// Before — public fields and an exposed mutable list; encapsulation is fiction.
public class ShoppingCart {
    public List<LineItem> items = new ArrayList<>();   // anyone can clear/replace it
    public double discountRate = 0.0;                  // anyone can set it to anything

    public double total() {
        double sum = 0;
        for (LineItem i : items) sum += i.price * i.qty;
        return sum * (1 - discountRate);
    }
}

// callers reach straight into internals:
cart.items.add(new LineItem("sku1", 9.99, 2));
cart.discountRate = 0.5;          // 50% off — no rule stops it
cart.items = null;                // and now total() NPEs

// After — internals are private; mutation goes through guarded methods.
public class ShoppingCart {
    private final List<LineItem> items = new ArrayList<>();
    private double discountRate = 0.0;

    public void addItem(LineItem item) {
        items.add(Objects.requireNonNull(item));
    }

    public List<LineItem> items() {
        return Collections.unmodifiableList(items);   // read-only view
    }

    public void applyDiscount(double rate) {
        if (rate < 0 || rate > 1) throw new IllegalArgumentException("rate out of range");
        this.discountRate = rate;
    }

    public double total() {
        double sum = 0;
        for (LineItem i : items) sum += i.price * i.qty;
        return sum * (1 - discountRate);
    }
}

// callers now go through the guarded API:
cart.addItem(new LineItem("sku1", 9.99, 2));
cart.applyDiscount(0.5);
// cart.items = null;  // no longer compiles

Exercise 7 — Retire the Constant Interface¶

Anti-pattern: Constant Interface. Goal: stop using implements to import constant names; give the constants a proper home. Constraints: the constant values and their use sites stay identical; only how they're accessed changes.

// Before — an interface of only constants; classes "implement" it to grab the names.
public interface HttpConstants {
    int OK = 200;
    int NOT_FOUND = 404;
    int SERVER_ERROR = 500;
    String DEFAULT_CHARSET = "UTF-8";
}

// classes inherit constants they don't really "implement":
public class ApiHandler implements HttpConstants {
    public Response handle(Request r) {
        if (r.path().equals("/missing")) return new Response(NOT_FOUND);   // unqualified
        return new Response(OK);
    }
}

// After — a real enum carries the codes; no class "implements" a bag of constants.
public enum HttpStatus {
    OK(200), NOT_FOUND(404), SERVER_ERROR(500);
    private final int code;
    HttpStatus(int code) { this.code = code; }
    public int code() { return code; }
}

public final class HttpDefaults {           // unrelated config constant, separate home
    private HttpDefaults() {}
    public static final String CHARSET = "UTF-8";
}

public class ApiHandler {                    // no longer "implements" anything for constants
    public Response handle(Request r) {
        if (r.path().equals("/missing")) return new Response(HttpStatus.NOT_FOUND.code());
        return new Response(HttpStatus.OK.code());
    }
}

Exercise 8 — Turn the BaseBean into a collaborator¶

Anti-pattern: BaseBean. Goal: stop inheriting from a "utility base" just to reach helper methods; obtain those helpers by composition instead. Constraints: preserve each subclass's observable output; the base's helpers must remain available where used.

// Before — subclasses extend a kitchen-sink base ONLY to call its helpers.
public class BaseService {                  // not a real "is-a" parent; a utility bag
    protected String fmt(double v) { return String.format("$%.2f", v); }
    protected void audit(String msg) { AuditLog.write(msg); }
    protected String now() { return Instant.now().toString(); }
}

public class InvoiceService extends BaseService {   // "is-a BaseService"? no — just wants fmt/audit
    public String render(Invoice inv) {
        audit("render " + inv.id());
        return "Invoice " + inv.id() + ": " + fmt(inv.amount());
    }
}

// After — capabilities are composed, not inherited; each is independently testable/mockable.
public final class MoneyFormatter {
    public String format(double v) { return String.format("$%.2f", v); }
}

public final class Auditor {
    public void write(String msg) { AuditLog.write(msg); }
}

public class InvoiceService {                       // no base class
    private final MoneyFormatter money;
    private final Auditor auditor;

    public InvoiceService(MoneyFormatter money, Auditor auditor) {
        this.money = money; this.auditor = auditor;
    }

    public String render(Invoice inv) {
        auditor.write("render " + inv.id());
        return "Invoice " + inv.id() + ": " + money.format(inv.amount());
    }
}

Exercise 9 — Fix Call Super with Template Method¶

Anti-pattern: Call Super (+ latent Fragile Base Class). Goal: remove the requirement that every subclass remember to call super.method(); make the base control the flow and the subclass supply only a hook. Constraints: preserve the order of operations (setup → work → teardown) and the produced result.

// Before — subclasses MUST call super.process() first, or auditing/locking silently breaks.
public abstract class Job {
    public void process() {
        acquireLock();          // every subclass must remember to run this first...
        audit("job start");     // ...and this. Forgetting = corrupted state, no compiler help.
    }
    protected abstract void doWork();
}

public class ReportJob extends Job {
    @Override
    public void process() {
        super.process();        // fragile: easy to forget, easy to call in the wrong place
        doWork();
        // oops — nothing releases the lock or audits completion; the contract is unwritten
    }
    protected void doWork() { /* build report */ }
}

// After — base owns the flow; subclass fills exactly one hook; super-calls are impossible to forget.
public abstract class Job {
    public final void process() {        // final: no subclass can break the flow
        acquireLock();
        try {
            audit("job start");
            doWork();                    // the single variation point
            audit("job complete");
        } finally {
            releaseLock();               // always runs, even on exception
        }
    }
    protected abstract void doWork();
}

public class ReportJob extends Job {
    @Override protected void doWork() { /* build report */ }   // that's all a subclass writes
}

Exercise 10 — Break the Fragile Base Class¶

Anti-pattern: Fragile Base Class. Goal: remove the implementation-inheritance coupling where a base method internally calls another base method that a subclass overrode, so a base change silently breaks subclasses. Constraints: preserve each class's observable counts/results; eliminate the hidden self-call dependency.

# Before — the classic self-call trap. addAll calls add; subclass overrode add → double-count.
class CountingSet:
    def __init__(self):
        self._items = []
        self.added = 0

    def add(self, x):
        self._items.append(x)
        self.added += 1

    def add_all(self, xs):
        for x in xs:
            self.add(x)            # base calls its own add — an undocumented internal contract

class LoggingSet(CountingSet):
    def add(self, x):
        print(f"adding {x}")
        super().add(x)             # fine for add()...

    def add_all(self, xs):
        print(f"adding {len(xs)} items")
        super().add_all(xs)        # ...but this re-enters self.add via the base loop:
                                   # every item is logged TWICE. Change base's add_all and it shifts again.

# After — composition; LoggingSet controls exactly when it logs, immune to base internals.
class CountingSet:
    def __init__(self):
        self._items = []
        self.added = 0
    def add(self, x):
        self._items.append(x)
        self.added += 1
    def add_all(self, xs):
        for x in xs:
            self.add(x)
    @property
    def count(self):
        return self.added

class LoggingSet:                      # has-a, not is-a
    def __init__(self, inner=None):
        self._inner = inner or CountingSet()

    def add(self, x):
        print(f"adding {x}")
        self._inner.add(x)

    def add_all(self, xs):
        print(f"adding {len(xs)} items")
        self._inner.add_all(xs)        # one delegation; no re-entry into LoggingSet.add

    @property
    def count(self):
        return self._inner.count

Exercise 11 — Rebuild the Functional Decomposition¶

Anti-pattern: Functional Decomposition. Goal: fix a "class" that is really a bag of static functions sharing no state — either make it honest free functions or give it the state that justifies an object. Constraints: preserve results; choose the simpler honest form for the actual usage.

# Before — a class with only @staticmethods and no instances; OO theater over free functions.
class TextUtils:
    @staticmethod
    def normalize(s):
        return s.strip().lower()

    @staticmethod
    def word_count(s):
        return len(TextUtils.normalize(s).split())

    @staticmethod
    def truncate(s, n):
        s = TextUtils.normalize(s)
        return s if len(s) <= n else s[:n] + "..."

# callers — TextUtils is never instantiated; it's a namespace pretending to be a class.
TextUtils.word_count("  Hello World  ")

# After (Python idiom) — honest module functions; no fake class.
def normalize(s):
    return s.strip().lower()

def word_count(s):
    return len(normalize(s).split())

def truncate(s, n):
    s = normalize(s)
    return s if len(s) <= n else s[:n] + "..."

# caller:
word_count("  Hello World  ")

Exercise 12 — Replace conditional with polymorphism¶

Anti-pattern: Flag Arguments driving a type-switch over an Anemic Model. Goal: eliminate a behavior-selecting enum/flag plus the conditional ladder it feeds, by letting each variant own its behavior. Constraints: same fees produced; adding a new account type must not require editing the calculator.

// Before — a "kind" flag + a switch; Account is anemic, the policy lives elsewhere.
type Account struct {
    Kind    string // "basic" | "premium" | "student"
    Balance float64
}

func MonthlyFee(a Account, waiveIfHighBalance bool) float64 {
    var fee float64
    switch a.Kind {                       // ladder grows with every new kind
    case "basic":
        fee = 5.0
    case "premium":
        fee = 0.0
    case "student":
        fee = 2.0
    default:
        fee = 5.0
    }
    if waiveIfHighBalance && a.Balance > 10000 {   // flag flips a second behavior
        fee = 0.0
    }
    return fee
}

// After — each type owns its fee; the waiver is a composable policy, not a flag.
type Account interface {
    MonthlyFee() float64
    Balance() float64
}

type Basic struct{ balance float64 }
func (b Basic) MonthlyFee() float64 { return 5.0 }
func (b Basic) Balance() float64    { return b.balance }

type Premium struct{ balance float64 }
func (p Premium) MonthlyFee() float64 { return 0.0 }
func (p Premium) Balance() float64    { return p.balance }

type Student struct{ balance float64 }
func (s Student) MonthlyFee() float64 { return 2.0 }
func (s Student) Balance() float64    { return s.balance }

// the former boolean flag becomes an explicit, reusable policy:
func FeeWithHighBalanceWaiver(a Account) float64 {
    if a.Balance() > 10000 {
        return 0.0
    }
    return a.MonthlyFee()
}

Exercise 13 — The full OO-misuse combo¶

Anti-pattern: six at once — Telescoping Constructor, Flag Argument, Magic Container, Anemic Domain Model, Poltergeist, and Object Orgy. Goal: refactor one notification feature exhibiting all of them, in a safe order. Constraints: preserve the sent-message content and channel; tackle the patterns from most-isolated to most-entangled.

// Before — a bit of everything in one feature.
public class Notification {
    public String channel;                 // Object Orgy: public mutable fields
    public String body;
    public boolean urgent;

    public Notification(String channel) { this(channel, "", false); }     // Telescoping...
    public Notification(String channel, String body) { this(channel, body, false); }
    public Notification(String channel, String body, boolean urgent) {     // ...constructor chain
        this.channel = channel; this.body = body; this.urgent = urgent;
    }
}

public class NotificationSender {
    // Poltergeist: exists only to forward to the gateway.
    private final Gateway gateway;
    public NotificationSender(Gateway g) { this.gateway = g; }
    public void fire(Notification n) { gateway.dispatch(n.channel, n.body); }
}

public class NotificationService {
    private final Gateway gateway;
    public NotificationService(Gateway g) { this.gateway = g; }

    // Flag Argument (preview) + Magic Container (Map) + Anemic Model (logic lives here, not on Notification)
    public void send(Map<String,Object> data, boolean preview) {
        String channel = (String) data.get("channel");
        String body = (String) data.get("body");
        boolean urgent = data.get("urgent") != null && (boolean) data.get("urgent");
        String finalBody = (urgent ? "[URGENT] " : "") + body;            // ASK + build outside
        if (preview) {
            System.out.println("preview " + channel + ": " + finalBody);
            return;
        }
        new NotificationSender(gateway).fire(new Notification(channel, finalBody, urgent));
    }
}

// After — rich, typed, encapsulated; one responsibility each.
public final class Notification {
    private final String channel;
    private final String body;
    private final boolean urgent;

    private Notification(Builder b) {
        this.channel = b.channel; this.body = b.body; this.urgent = b.urgent;
    }
    public static Builder to(String channel) { return new Builder(channel); }

    public String channel() { return channel; }
    public String renderedBody() {                  // behavior lives WITH its data
        return (urgent ? "[URGENT] " : "") + body;
    }

    public static final class Builder {
        private final String channel;
        private String body = "";
        private boolean urgent = false;
        private Builder(String channel) { this.channel = channel; }
        public Builder body(String b)   { this.body = b; return this; }
        public Builder urgent(boolean u){ this.urgent = u; return this; }
        public Notification build()     { return new Notification(this); }
    }
}

public class NotificationService {
    private final Gateway gateway;
    public NotificationService(Gateway g) { this.gateway = g; }

    public void send(Notification n) {                          // no flag, no map, no poltergeist
        gateway.dispatch(n.channel(), n.renderedBody());
    }

    public void preview(Notification n) {                       // the flag's other behavior, named
        System.out.println("preview " + n.channel() + ": " + n.renderedBody());
    }
}

// call site — typed, labelled, intention-revealing:
Notification n = Notification.to("sms").body("hi").urgent(true).build();
service.send(n);     // or service.preview(n);

Refactoring discipline — the recap¶

The exercises above all run the same loop. Internalize it and the specific moves become mechanical:

green  →  one named refactoring  →  green  →  commit  →  repeat
          (behavioral change, if any, gets its OWN commit)

• Characterize at the public seam. With OO, behavior moves behind the interface — so pin behavior through public methods (return values and collaborator interactions, via spies/mocks). That test stays green while logic migrates from a service into an entity, from a subclass into a delegate, from a Map into a struct.
• Small, reversible steps. Encapsulate one field, run tests, commit. Move one method, run tests, commit. If green turns red, your last step is the suspect — revert it.
• Separate structural from behavioral commits. Tightening a setter's validation (Exercise 6), releasing a lock on exception (Exercise 9), fixing a double-log (Exercise 10), or removing a now-impossible error/default (Exercises 3, 12) are behavioral deltas — each gets its own reviewed commit after the structure is clean.
• Name the move. "Remove Flag Argument," "Replace Constructor with Builder," "Replace Magic Container with Class," "Move Method / Tell-Don't-Ask," "Remove Middle Man," "Encapsulate Field / Collection," "Replace Inheritance with Delegation," "Form Template Method," "Replace Conditional with Polymorphism." Naming the move means it's a known-safe, often IDE-automatable transformation — not an improvisation.
• Favor composition over inheritance. Most OO-misuse cures (BaseBean, Call Super, Fragile Base Class) converge on the same direction: turn implementation-inheritance into delegation, and reserve inheritance for sealed Template Methods with an enforced contract.
• Don't over-correct. Don't replace every inheritance with a delegation maze, every constructor with a Builder, or every service with an entity method. Push the entity's own rules into the entity, keep services for orchestration, and reach for Builder only when optionals are many. Over-correcting trades OO misuse for the over-engineering smells (Speculative Generality, Lazy/Middle-Man classes) catalogued in Refactoring → Code Smells.

Related Topics¶

• tasks.md — guided exercises building these moves from scratch.
• find-bug.md — the spotting counterpart: identify the OO-misuse anti-pattern, don't fix it.
• junior.md · middle.md · senior.md · professional.md — recognize → countermove → refactor-at-scale.
• Refactoring → Refactoring Techniques — the mechanical catalog for every move named above.
• Refactoring → Dealing with Generalization — Replace Inheritance with Delegation, Form Template Method, the inheritance-vs-composition decisions behind Exercises 8–10.
• Clean Code → Objects and Data Structures — Tell-Don't-Ask and the data-vs-object distinction, the target state for Exercise 4.
• Clean Code → Classes — SRP and cohesion behind the encapsulation and delegation cures.
• Design Patterns → Creational → Builder — the positive counterpart to Telescoping Constructor.
• Design Patterns → Behavioral → Template Method — the positive counterpart to Call Super.