Exercise 3: Why Order Can Swap at Runtime But Tea Can't Become Coffee — Possible Solution ==================================================================== WHAT MAKES THE ORDER SWAP POSSIBLE ------------------------------ This chapter verified that an Order object HOLDS A REFERENCE to a separate strategy object (self.shipping_strategy) rather than being one. set_shipping_strategy() just reassigns that one attribute to point at a different object - the Order object itself never gets rebuilt, destroyed, or replaced; only which object it currently points to for "how do I calculate shipping" changes. That's why the same order object could report 12.5, then 35.0, then 77.5, then 0 across four swaps - each swap only changed what shipping_strategy pointed to. WHY A Tea OBJECT CAN'T BECOME A Coffee THE SAME WAY ------------------------------ Tea and Coffee aren't objects that HOLD a reference to their own brewing behavior the way Order holds a reference to its strategy - they ARE their behavior, baked in at the class level through inheritance. brew() and add_condiments() aren't attributes that can be reassigned at runtime; they're methods defined on the Tea class itself (or the Coffee class itself), resolved through Python's own method lookup the instant prepare_recipe() calls self.brew(). There's no "strategy slot" on a Tea instance to point somewhere else, because Template Method never created one - the whole point of Chapter 7's comparison table was that Template Method's variation lives in class definitions, not in swappable object references. WHAT YOU'D HAVE TO DO INSTEAD ------------------------------ To get Coffee-shaped behavior where a Tea object currently sits, you would have to create an actual new Coffee() object and use that instead - there's no operation that mutates an existing Tea instance into behaving like a Coffee instance. This is the direct, practical consequence of the "can it change after the object is created?" row in this chapter's own comparison table: Strategy's answer is yes, by design; Template Method's answer is no, also by design - swapping which CLASS an object belongs to isn't something normal object-oriented code does at all, whereas swapping which OBJECT an attribute points to is exactly what Strategy relies on. WHY THIS WORKS AS AN ANSWER ------------------------------ The explanation traces the mechanical reason for each pattern's own behavior back to this chapter's own verified code (an attribute reference vs. a class-level method), rather than only restating the comparison table's conclusion, and it states concretely what the only real alternative is (creating a new object of the desired subclass) instead of implying Template Method has some hidden runtime-swap mechanism it doesn't.