Exercise 3: What Adding the Same Rule Would Have Cost in the Tangled Version — Possible Solution
====================================================================

WHERE THE CHANGE WOULD HAVE TO GO
------------------------------
This chapter's own process_order_bad() computes discount with:

    if customer_type == 'vip':
        discount = items_total * 0.20
    elif customer_type == 'loyalty':
        discount = items_total * 0.10
    else:
        discount = 0

Adding "$5 off orders over $50 for new customers" would require adding
a new elif branch to this SAME if/elif chain, something like:

    elif customer_type == 'new':
        discount = 5 if items_total > 50 else 0

This branch has to be inserted into the EXACT SAME block of code that
already handles two unrelated discount rules (vip, loyalty) - there is
no way to add this rule without editing a function that also computes
shipping cost, tracks status, and sends notifications, all in the same
64-ish lines.

WHY THIS IS RISKIER THAN EXERCISE 2'S CHANGE
------------------------------
Exercise 2 added NewCustomerDiscount as a completely new, separate
class - it was never possible for that change to accidentally break
VipDiscount, LoyaltyDiscount, or NoDiscount, because none of that
existing code was touched at all. Editing process_order_bad()'s own
if/elif chain instead means:

  - A typo or misplaced elif could silently change behavior for VIP
    or loyalty customers too, since all three branches live in the
    same block and share the same variable (discount).
  - Testing the change means re-running (or re-reasoning about) the
    ENTIRE process_order_bad() function - shipping, status, and
    notification logic included - even though none of that logic was
    supposed to change.
  - Every future discount rule added the same way makes the if/elif
    chain longer and the risk of the next edit accidentally breaking
    an earlier branch higher - this is exactly the "adding a new
    customer type means editing code that has nothing to do with
    shipping or notifications" problem this chapter's own warn-box
    named directly.

THE UNDERLYING REASON
------------------------------
In the refactored version, "add a new discount rule" and "modify
existing discount rules" are physically different actions on different
files - you can only do the first one by construction, since each
strategy is its own standalone class. In the tangled version, both
actions look identical: editing lines inside the same shared function.
The tangled code doesn't prevent a change from being risky; it just
doesn't distinguish a safe addition from a risky modification at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
The answer identifies precisely which existing block of tangled code
the new rule would have to be inserted into, explains concretely how
that insertion could interact badly with the unrelated code already
sharing that block, and ties the risk back to this chapter's own
already-stated warn-box problem rather than only asserting the tangled
version is "worse" in the abstract.