Exercise 3: What Each Pattern Prevents, and Why a Single-Parameter Class Needs Neither — Possible Solution
====================================================================

WHAT ABSTRACT FACTORY SPECIFICALLY PREVENTS
------------------------------
This chapter verified Abstract Factory prevents INCONSISTENT
COMBINATIONS of multiple related objects that are meant to always be
used together - the reproduced bug was a mismatched LightButton paired
with a DarkCheckbox, something that compiles and runs perfectly but
produces a visually broken result. The pattern is about ensuring
several different objects, created together, all belong to the same
"family."

WHAT BUILDER SPECIFICALLY PREVENTS
------------------------------
This chapter verified Builder prevents PARAMETER MIX-UPS when
constructing a single complex object that has many optional or
easily-confused fields - the reproduced bug was a positional argument
landing in the wrong constructor parameter (gpu instead of
case_color), silently producing a wrong object with no error. The
pattern is about ensuring one object's own many possible fields are
each set correctly and unambiguously.

WHY A SINGLE-REQUIRED-PARAMETER CLASS NEEDS NEITHER
------------------------------
Abstract Factory's whole purpose is coordinating MULTIPLE related
objects so they stay consistent with each other - a class that only
ever produces one single, standalone object has no "family" of
related objects to keep consistent in the first place, so there's
nothing for Abstract Factory to protect against. Builder's whole
purpose is preventing mix-ups among MULTIPLE parameters, particularly
optional ones that could be confused with each other positionally - a
class with only one required parameter has no possible position-mixup
to make: there's only one argument, so there's no way to accidentally
put it in the "wrong slot," and no optional fields whose absence or
presence needs tracking.

THE GENERAL PRINCIPLE
------------------------------
Both patterns solve real problems that specifically arise from
COMPLEXITY - either complexity across multiple related objects
(Abstract Factory) or complexity within a single object's own many
fields (Builder). A simple, single-parameter class has neither kind of
complexity, so introducing either pattern there would be exactly the
kind of unnecessary indirection Chapter 1's own honest warning
described - solving a problem the code doesn't actually have.

WHY THIS WORKS AS AN ANSWER
------------------------------
The answer precisely distinguishes what each pattern's own verified
bug demonstration actually protected against (cross-object consistency
vs. single-object parameter clarity), and explains why a
single-required-parameter class structurally lacks the specific kind
of complexity each pattern exists to manage, tying the conclusion back
to Chapter 1's own over-engineering warning.