Exercise 3: A Fifth Call Site That Genuinely Uses the Hook — Possible Solution
====================================================================

THE NEW CALL SITE
------------------------------
    def apply_ten_percent_off(price):
        return price * 0.9

    call_sites.append(lambda: calculate_price(100, discount_strategy=apply_ten_percent_off))

A genuine, real-looking discount function is defined and actually
passed to calculate_price's own discount_strategy parameter.

RESULTS
------------------------------
    total call sites: 5
    call sites using a custom discount_strategy: 1
    result of the new call site: 90.0

Re-running this chapter's own check across all 5 call sites: exactly 1
of them (the new one) now uses the custom strategy - up from 0 of 4.
The new call correctly computes 90.0 (100 * 0.9), confirming the
discount_strategy parameter isn't just accepted syntactically, it
genuinely changes the computed result when supplied.

IS THIS STILL SPECULATIVE GENERALITY?
------------------------------
No - and this is the entire point of this chapter's own test. This
chapter's original finding wasn't "any flexible parameter is
automatically speculative generality" - it was "flexibility that has
NEVER been exercised by real code is speculative." The moment one real
call site genuinely uses the hook for a real purpose, the parameter has
crossed from "might be needed later" (unproven, this chapter's own
original 0-of-4 finding) to "is actually needed, verified by an actual
caller" (1-of-5, now proven). The mechanism (the discount_strategy
parameter itself) didn't change at all between the two states - only
whether real code actually exercises it did.

WHY THIS CONFIRMS THE TEST IS THE RIGHT ONE
------------------------------
This is exactly why this chapter's own check is defined as "does ANY
real call site use the non-default value," not "could a call site
theoretically use it" or "does the code support it." The test is
empirical and revisable - a parameter correctly flagged as speculative
generality today can stop being speculative the moment a genuine use
appears, without the underlying code needing to change at all. This
mirrors Design Patterns Chapter 10's own conclusion directly: whether
something counts as over-engineering depends on whether the codebase
actually needs it, not on whether the capability exists.

WHY THIS WORKS AS AN ANSWER
------------------------------
A genuinely new, functioning call site is added rather than a
placeholder, this chapter's own exact check is re-run and shows the
count moving from 0 to 1, and the conclusion (no longer speculative)
is grounded in the check's own defined criterion rather than a general
judgment about the parameter's design.