Exercise 2: Why "Solution Shape" Beats "Copy-Paste Code" as a Description — Possible Solution ==================================================================== WHY "COPY-PASTE CODE" DOESN'T MATCH WHAT THIS CHAPTER ACTUALLY VERIFIED ------------------------------ This chapter's own two implementations of the discount calculator - the if/elif version and the object-based version - are not the same code at all. They have different function signatures, different control structures, and entirely different sets of classes. If design patterns were literal reusable code, these two would have to look similar to both count as valid examples - but they don't, and both are legitimate, working implementations. What they DO share is not any actual code, but an underlying STRUCTURE: in the object-based version specifically, the idea of representing each possible behavior as its own interchangeable object with a common interface (apply) - that structural idea is the reusable thing, not any particular line of code implementing it in Python. WHY "SOLUTION SHAPE" IS THE MORE ACCURATE DESCRIPTION ------------------------------ A "shape" describes the general structure of a solution - which pieces exist, how they relate to each other, what each piece's job is - without dictating the exact syntax, language, or naming used to build it. This chapter's own verified extensibility result (adding LoyaltyDiscount touched zero existing code) is a property of the SHAPE itself - any implementation of "represent each behavior as its own object with a shared interface," in any language, would get that same extensibility benefit, even though the actual code implementing it would look completely different from one codebase to the next. WHY THIS DISTINCTION MATTERS IN PRACTICE ------------------------------ Treating patterns as copy-paste code would mean literally lifting Python class definitions into, say, a Java or JavaScript codebase, which usually doesn't even make direct sense given each language's own different syntax and conventions. Treating a pattern as a shape means recognizing "this situation calls for a Strategy-like structure" and then implementing that structure in whatever way fits the target language naturally - which is the actual, portable skill this course is teaching, confirmed by this chapter's own demonstration that the identical underlying idea can be expressed in genuinely different concrete code. WHY THIS WORKS AS AN ANSWER ------------------------------ The explanation grounds the distinction directly in this chapter's own two verified implementations (genuinely different code, same underlying idea), identifies specifically what is being reused (the structural relationship between pieces, not any literal code), and explains why this distinction has real practical consequences rather than being merely a semantic preference.