You now know the five creational patterns individually. This final lesson of the module puts them on the same table, which is where real decisions get made: the question is rarely "how does Builder work?" but "what do I use here: a builder, a factory, or nothing?". We will compare intents and costs, give you a decision guide in diagram form, see how they combine with one another (in real code they almost never appear alone), and trace their typical evolution over a project's life. We will close with PideYa's complete creational map: which pattern ended up installed in each part of the system and why.

1. The five, face to face
2. Decision guide
3. How they combine with one another
4. The typical evolution: patterns are earned
5. PideYa's creational map
6. Common mistakes, exercises, and conclusion

The table worth internalizing (the cost columns pick up the scale from lesson 01-06):

Two cross-cutting axes that help keep them apart:

• Where is the difficulty? In choosing the class → factories (one piece: Factory Method; a consistent family: Abstract Factory). In assembling the object → Builder. In the starting point (an equal one already exists) → Prototype. In how many instances → Singleton.
• What do you feed the mechanism? A factory gets parameters and decides the class; a builder gets data bit by bit and assembles; a prototype gets nothing: it already contains its state.

The question flow that sums up the module. Like every guide, it steers 90% of cases; the remaining 10% is judgment (and remember the filter that precedes them all: does the direct new actually hurt?):

Three tips for using the guide:

• The answers can be several at once: a complex order (Builder) whose payment gateway is chosen by a market factory (Abstract Factory) is the norm, not the exception. The guide applies per creation decision, not per system.
• When torn between Factory Method and Abstract Factory, the discriminating question is always the same: is there a consistency invariant across several products? No family, no Abstract Factory.
• When torn between Builder and a factory: the factory hides which class; the builder hides which steps. If the client knows the class perfectly (Order) but suffers assembling it, it is Builder.

The creational patterns are Lego pieces, and in real code they show up assembled. The canonical combinations, all present or plausible in PideYa:

• Abstract Factory implemented with Factory Methods. Each createX() method of SpainFactory is a factory method: the abstract factory is, structurally, a bundle of factory methods grouped by variant. You saw it in lesson 02-04.
• Factories exposed as a Singleton (or better, injected as a single instance). MexicoFactory has no state of its own: there is no reason to instantiate it more than once. The usual arrangement: a single instance created at the composition root and injected; the classic Singleton remains for the container-less case.
• A Builder inside a factory. A factory whose product is complex assembles it internally with its builder: SpainFactory.createReceiptFormatter() may return ReceiptFormatter.builder().regulation(ES).currency(EUR).build(). The client sees a factory; the factory uses a builder. Each pattern solves its own layer.
• A factory that returns the builder. Order.builder(customer, restaurant) — our entry point from lesson 02-05 — is a static creation method... that manufactures a builder. The combination is so natural it goes unnoticed.
• Abstract Factory implemented with Prototype. Instead of one factory class per market, a set of prototypical exemplars per market that the factory copies. Useful when variants are defined by configuration (data) rather than by code.
• A registry (of Suppliers or of prototypes) as the backbone. The registry from lesson 02-03 and the template registry from lesson 02-06 are the same skeleton with different filling: recipes in one, exemplars in the other. Both turn "adding a variant" into "registering an entry", without touching the core.

The sequence you saw in the lessons is no accident: it is the natural trajectory of a creation point over the life of a healthy project. It pays to make it explicit, because it tells you when to stop:

Each arrow has an entry toll: the symptom that justifies it. Walking the whole road "just in case" on day one is the over-engineering of lesson 01-06; staying at direct new when there are already three duplicated switch blocks is the symmetric mistake. PideYa walked the full sequence only for payments and taxes (where internationalization demanded it); notifications stopped at the Supplier registry; and dozens of small objects happily remain at direct new. All three stops are correct: each is the proportionate answer to its level of pain. Builder and Prototype orbit outside this sequence: they do not evolve from the factory but from the object (a swelling constructor → Builder; repetitive rebuilding → Prototype). And the reverse road exists too: if an Abstract Factory's variants shrink to one and nothing suggests they will return, downgrading it to a simple factory is good refactoring, not surrender (more on this in Refactoring with Design Patterns).

Let's close the module the way it began: looking at the whole system. This is what ended up installed, lesson by lesson, with its one-line justification:

Note the last row: it is as important as the rest. A mature design is not the one with the most patterns, but the one with each pattern where its symptom justified it — the yardstick we set in the lesson on the scale.

• Choosing by familiarity, not by problem. "I use Factory Method because it's the one I know best" produces factories where a builder was needed. The decision guide exists to force the right questions before the comfortable answers.
• Confusing the star pair. Factory Method and Abstract Factory will keep getting mixed up in interviews and reviews; recite the discriminator: a method that creates one product versus an object that creates a consistent family.
• Skipping rungs of the evolution. Setting up the market Abstract Factory when PideYa operated only in Spain would have been pure speculative flexibility. Each arrow's toll is paid when the symptom arrives, not before.
• Not dismantling patterns that no longer pay. The evolution also runs backwards: keeping a factory hierarchy for a single variant two years running is structural debt dressed up as design.
• Treating the combinations as exceptions. A builder inside a factory, or a factory that returns builders, is not "mixing patterns": it is the norm. Each pattern governs one layer of the creation decision.
• Tip: on your next project, do the map exercise: a table like PideYa's with every relevant creation point, its solution, and its one-line justification. If any row cannot be justified with a symptom, you have a candidate for simplification.

For each new situation in PideYa, pick the creational pattern (or the absence of one) and justify it in one sentence using the right discriminator:

1. The reporting module must generate a StatisticsPanel object with 12 configurable widgets, optional thresholds, and range validation.
2. Marketing wants email campaigns whose content is defined visually in an admin panel; each new campaign starts from an existing one "that worked".
3. When integrating in-store pickup for supermarkets, each chain (Mercadona, Carrefour) demands its own stock API, its barcode format, and its loyalty gateway, always matching.
4. A developer proposes making the CurrentCart a singleton "to access it from any screen of the app".
5. The right DataExporter object (CSV, JSON, or Parquet) must be created based on a parameter; today there are three formats and no families or consistency requirements are expected.

Describe which creational patterns collaborate in this fragment and what role each one plays:

PideYa's promo code generator was born as new CodeGenerator() in a single service. Today: (a) marketing wants alphanumeric codes for regular campaigns and QR codes for billboard campaigns; (b) the switch distinguishing them is already copied into two services. Describe the step-by-step evolution that applies the section 4 sequence, indicating at which stop you would halt today and which future symptom would push you to the next one.

Solution 1:

1. Builder: the class is known and the problem is the assembly (optionals + cross-field validation).
2. Prototype with a registry: the exemplars are defined with data at runtime and the natural starting point is an existing campaign; no solution based on new classes fits an admin panel.
3. Abstract Factory: three pieces per chain with a consistency invariant ("always matching"): a textbook family.
4. No pattern, plus a reasoned rejection: the cart is mutable, per-user business state; a singleton would share it across sessions (a serious bug) and hide the dependency. It belongs to the session/context, injected.
5. Simple factory (or a Supplier registry if more formats are expected): one product, no families; with three stable cases, the idiom is enough and the full pattern would be ceremony.

Solution 2: the collaborators are Abstract Factory (the MexicoFactory class, which guarantees the Mexican market's consistent family), Factory Method (the createReceiptFormatter() method is one of its factory methods: it decides this variant's concrete product), and Builder (ReceiptFormatter.builder()...build() assembles the complex product step by step, with whatever validation belongs in build()). Three layers of the same decision: which family → which product → how it is assembled.

Solution 3: a reasonable evolution: (1) the direct new stopped being enough when the second concrete class appeared (alphanumeric/QR) and the switch got duplicated: clear symptoms → extract a simple factory (CodeGeneratorFactory.create(type)) that deduplicates and centralizes. (2) Current stop: that is where I would halt today — two stable variants and a single decision point justify no more. (3) The symptom that would push toward Factory Method/a Supplier registry: new variants arriving at a real cadence (codes per partner, per external app) or the need for other modules to register generators without touching the core. (4) Abstract Factory would only enter if some day each campaign demanded several consistent pieces (generator + validator + renderer, matching per campaign type); that family does not exist today, so anticipating it would be speculation.

The module opened with a question — who decides which concrete class gets instantiated, and where? — and you now have five answers with their discriminators: Singleton for uniqueness (better: injection), Factory Method to vary the product, Abstract Factory to lock in families, Builder to tame assembly, Prototype to start from an exemplar. You know they combine in layers, that you arrive at them through a symptom-driven evolution — and leave them the same way — and you have PideYa's map as a template of the end result: each pattern where its pain justified it, and direct new where there was no pain.

With the birth of objects solved, the next question is inevitable: once the pieces are created — gateways, notifiers, orders — how do they connect and organize without the whole turning into a tangle? That is the catalog's second family: adapting interfaces that do not fit, composing tree structures, wrapping objects with extra responsibilities, simplifying entire subsystems behind a facade. See you in the Introduction to Structural Patterns.