Exercise 3: Why "Always Use the Object-Based Version" Is Bad Advice for a Fixed Boolean Flag — Possible Solution ==================================================================== WHAT'S TRUE ABOUT THE OBJECT-BASED VERSION'S BENEFIT ------------------------------ This chapter did verify a genuine, measurable benefit to the object-based approach: adding a new discount type touched zero existing code. This is a real advantage specifically for the discount calculator scenario, where new discount types are a realistic, recurring kind of future change. WHY THE DEVELOPER'S "ALWAYS" IS WRONG HERE ------------------------------ This chapter's own honest warning specifically addressed this exact situation: the object-based shape's benefit is that ADDING a new case requires no changes to existing code - but this benefit is only worth anything if new cases are actually going to be added. The developer's own scenario explicitly states the flag will only ever have two possible values and will never change - meaning the specific benefit this chapter verified (avoiding edits to existing code when a NEW case arrives) can never actually be exercised, because no new case is ever going to arrive. WHAT USING THE OBJECT-BASED VERSION WOULD COST HERE INSTEAD ------------------------------ Applying the object-based shape anyway would mean creating a class hierarchy, an interface, and passing objects around, all to represent something that a single boolean check (if flag: ... else: ...) would express far more directly and readably. This is precisely the "extra indirection for nothing" scenario this chapter's own warning described - the code becomes harder to read and navigate, without the extensibility benefit ever paying off, since there's no future extension coming. THE CORRECTED PRINCIPLE ------------------------------ The choice between these two shapes should be based on whether the number of cases is genuinely expected to grow or change over the system's lifetime - not applied as a fixed rule regardless of context. A two-value, permanently-fixed flag is exactly the kind of case this chapter's own example (a discount type that legitimately keeps growing) was NOT - and the developer's "always" ignores that the benefit this chapter verified is conditional on recurrence, not automatic. WHY THIS WORKS AS AN ANSWER ------------------------------ The answer credits what this chapter's evidence genuinely supports (the object-based version's real extensibility benefit) while correctly identifying that the developer's specific scenario lacks the one condition (a realistically recurring need for new cases) that benefit depends on, directly citing this chapter's own stated warning rather than treating the object-based approach as unconditionally superior.