Exercise 3: Why Isolation Held for Two Different Changes, Not by Coincidence — Possible Solution ==================================================================== WHAT THE TWO VERIFIED CHANGES ACTUALLY HAD IN COMMON ------------------------------ This chapter's own platinum-tier change touched only apply_tier_ discount(). Exercise 2's own threshold change touched only apply_bulk_ discount(). On the surface these look like two unrelated successes - but both changes share the same underlying property: each one modified exactly the piece of business logic that ONE function, and only one function, was responsible for. Tier discounts live in apply_tier_ discount() and nowhere else; the bulk-discount threshold lives in apply_bulk_discount() and nowhere else. THE DESIGN PROPERTY THAT MAKES THIS GENERALIZE ------------------------------ calculate_order_total() itself never contains any of the actual business rules - it only calls, in sequence, four functions that each own exactly one rule (item totaling, tier discount, bulk discount, express fee). Because each function's own body is the ONLY place its own specific rule is expressed, changing that rule can only ever require editing that one function - there is no second copy of the tier-discount logic hiding inside apply_bulk_discount(), and no piece of the bulk-discount threshold hiding inside apply_tier_discount(). This is precisely why BOTH verified changes, despite touching different functions, produced the identical isolation result: the design doesn't make one specific change safe, it makes an entire CATEGORY of changes (any change confined to one already-separated concern) safe by construction. WHY THIS WOULDN'T HOLD FOR EVERY POSSIBLE CHANGE ------------------------------ This isolation property specifically covers changes that stay within one existing concern's own boundary. A change that genuinely spans multiple concerns - for example, "apply the bulk discount only to non-express orders," which would require both apply_bulk_discount() and knowledge of the express flag - would legitimately require editing more than one function, or restructuring how the functions relate to each other. The guarantee isn't "every change is isolated no matter what" - it's "a change confined to one already-separated responsibility stays confined to the one function that owns it," which is exactly what both of this chapter's own verified changes were. WHY THIS WORKS AS AN ANSWER ------------------------------ The explanation identifies the specific shared property behind both verified changes (each one modified exactly one function's own single responsibility) rather than treating them as two separate lucky outcomes, and it honestly states the boundary of the guarantee - which kinds of changes it does and doesn't cover - rather than overclaiming that the clean design makes all changes equally safe.