Exercise 3: Two Independent Orders Through One OrderService — Possible Solution
====================================================================

SETUP
------------------------------
    inventory = {'widget': 50, 'gadget': 30}
    service = OrderService(CreditCardPayment())

    Order 1: widget x2, GoldDiscount, StandardShipping
    Order 2: gadget x3, PlatinumDiscount, StandardShipping

RESULTS
------------------------------
    Order 1: {'total': 41.0, 'receipt': 'Charged $41.00 to card', 'loyalty_points': 40}
    Order 2: {'total': 41.0, 'receipt': 'Charged $41.00 to card', 'loyalty_points': 40}

    Inventory after both: {'widget': 48, 'gadget': 27}

    Order 1 correct: True
    Order 2 total: 41.0, expected 41.0 (45*0.8+5), correct: True
    Order 2 loyalty points: 40, expected 40
    Inventory correct: True

Both orders happen to total $41.00 by coincidence of the chosen
numbers (40*0.9+5 = 45*0.8+5 = 41), but each is computed entirely
independently - verified against its own hand-calculated expected
value, not assumed equal because the results matched.

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms the same guarantee Clean Code, SOLID & Refactoring's own
capstone Exercise 3 established for the underlying system: one shared
OrderService instance processing multiple genuinely different orders
in sequence produces correct, independent results for each, with
inventory correctly reflecting both orders' own deductions. This
capstone's own contribution is confirming that guarantee holds all the
way through the fully assembled test strategy - not just for the raw
pricing and inventory logic, but for the newer loyalty-points feature
layered on top of it in Steps 5 and 6, which correctly computes a
fresh, independent value for each order rather than accumulating or
interfering across calls.