Twenty-three patterns are too many to tackle in no particular order. That is why the Gang of Four organized them into a map with two axes — the pattern's purpose and its scope — which remains the standard way to navigate the catalog. This lesson is exactly that: the map of the territory you will cover in modules 2, 3 and 4. You will see the three families (creational, structural and behavioral), the question each one answers, the complete table of the 23 patterns with their purpose in one line, and a mention of the families left out of the GoF that we will visit in module 6. We will not develop any individual pattern: today is for getting oriented, not for digging.

1. The GoF's two classification axes
2. First axis: purpose (the three families)
3. The 23 patterns, family by family
4. Second axis: scope (class versus object)
5. Beyond the GoF: other pattern families
6. The map as the course itinerary

The Design Patterns book classifies its 23 patterns using two orthogonal criteria:

• Purpose: what kind of problem does the pattern solve? This gives rise to the three families: creational (how objects are created), structural (how they are composed) and behavioral (how they collaborate and share responsibilities).
• Scope: does the pattern operate on classes (relationships fixed at compile time, via inheritance) or on objects (relationships established at runtime, via composition)?

The first axis is the one everyone uses to talk about patterns and the one that structures this course; the second is subtler but very revealing, and we will look at it in section 4.

A useful intuition for remembering the three families with PideYa: think about the lifecycle of a system's objects. First they must be created (who does the new for the right payment gateway?), then organized into larger structures (how do you assemble a menu that contains dishes and other menus?), and finally made to collaborate (how does the courier find out the order changed status?). Creation → structure → behavior.

Question they answer: how do you create objects without coupling the code to the concrete classes it instantiates, and how do you control how many instances exist and how the complex ones are assembled?

As we saw when studying the design principles, the new is the point where a concrete class is inevitably named. The creational patterns exist to isolate and centralize those points, so the rest of the system programs to interfaces. In PideYa, these are the patterns that will answer "who decides whether the payment is processed with the card gateway or with PayPal?" or "how do you build an order with lines, discounts, address and tip without a ten-parameter constructor?".

Question they answer: how do you combine classes and objects into larger structures that remain flexible and efficient?

These are the patterns of composition: wrapping an object to add something to it, adapting a foreign interface to the one your code expects, treating an element and a group of elements alike, or putting a simple facade in front of a convoluted subsystem. In PideYa they will appear when we integrate the API of an external payment provider that does not fit our interfaces, or when we model menus containing sections containing dishes.

Question they answer: how do you distribute responsibilities among objects and organize the communication between them so each one does its job without coupling to the rest?

It is the largest family, because collaboration is the hardest thing to design. This is where the patterns live that solve the Order notification problem we saw in the first lesson, the ones that model an order's state cycle (received → preparing → out for delivery → delivered), and the ones that allow swapping algorithms (delivery-fee calculation strategies) at runtime.

Here is the complete catalog. Do not try to memorize it today: use it as an index to come back to. Each pattern has its own lesson in modules 2–4.

Tally: 5 + 7 + 11 = 23. As a reference for practical weight: they do not all matter equally in day-to-day work. Singleton, Factory Method, Builder, Adapter, Decorator, Facade, Observer, Strategy, Template Method and Command come up constantly; Interpreter or Flyweight are far more occasional. In each pattern's lesson and in the comparison lessons that close each module (02-07, 03-09, 04-13) we will refine this relative weight.

The GoF's second criterion asks how the pattern establishes its relationships:

• Class scope: the key relationship is fixed through inheritance, at compile time. Once compiled, the behavior is decided.
• Object scope: the key relationship is established through composition: references between objects that can be changed at runtime.

Two valuable observations from this table:

1. The overwhelming majority of patterns are object-scoped. It is the maxim "favor composition over inheritance" turned into statistics: out of 23 patterns, only a handful rely on inheritance as their central mechanism.
2. There are pairs of patterns that solve similar problems, one via class and one via object (you will see it, for example, between Template Method and Strategy, or between the two Adapter variants). Understanding the scope axis will give you the criterion for choosing: inheritance is simpler but rigid; composition, more flexible but with more moving parts.

The GoF map covers class and object design inside an object-oriented application. As we saw in the history lesson, the community kept harvesting patterns at other levels. The families worth having on your radar:

• Architectural patterns: they decide the overall shape of the system, not of a few classes (layers, MVC, microkernel, broker...). They operate at a larger scale than the GoF.
• Concurrency patterns: they coordinate threads and shared resources (producer-consumer, thread pool, reactor...).
• Enterprise and integration patterns: persistence, transactions and messaging between systems (Repository, Unit of Work, queues and channels...).
• Microservices and distributed-systems patterns: resilience and coordination between remote services (API Gateway, Circuit Breaker, Saga...).

All these families are covered in module 6 (modern architectures, microservices, distributed systems and concurrency); for now it is enough to place each at its scale:

This classification is not just theory: it is literally the index of what is coming. Your itinerary:

Every pattern module also follows the same rhythm: an introduction to the family, one lesson per pattern (with the problem posed in PideYa) and a final comparison for choosing among similar patterns. The order creational → structural → behavioral is no accident: it replicates the natural cycle create → compose → collaborate, and each family builds on the previous ones.

• Trying to memorize all 23 at once. It is useless and demoralizing. Today you only need the three family questions (creation? structure? collaboration?) and to know the table exists to be consulted.
• Treating the family as a rigid drawer. Some patterns have a foot in two worlds, and in practice they are combined constantly (a factory that returns strategies, a composite traversed by a visitor). The classification orients; it does not confine.
• Ignoring the scope axis. Almost everyone knows the three families and almost no one knows the class/object axis, which is precisely the one that explains why "twin" pattern pairs exist and which to choose. Keeping it in mind will give you an edge in modules 3 and 4.
• Believing the GoF map is the whole territory. If you only know the 23, you will try to solve with them problems that belong to another scale (architecture, distribution, concurrency). Part of good judgment is knowing when your problem is not even in this family; module 6 exists for that.
• Tip: print or save the three tables from section 3. Returning to them after studying each pattern ("do I still agree with this summary line?") is an excellent review technique: when every line seems obvious to you, you will have mastered the catalog.

For each problem, state which family of patterns (creational, structural or behavioral) would address it. Do not name specific patterns: reason only from the nature of the problem.

1. When an order moves to "delivered", the customer, the loyalty system and the statistics must find out.
2. The external map provider has an API with methods and types that do not fit PideYa's routing interfaces.
3. Assembling a valid Order object requires combining cart, address, time slot, discounts and tip, with many optional combinations.
4. A restaurant's menu contains sections, which contain dishes or sub-sections, and prices and allergens must be computed over the whole.
5. Depending on the country, PideYa must use a complete, coherent set of: payment gateway, tax calculator and receipt formatter.

Without knowing the patterns yet, reason it out: why does an object-scoped pattern allow changing behavior at runtime while a class-scoped one does not? Illustrate it with the Courier and its Vehicle example from the principles lesson.

State whether each problem belongs to GoF territory or to another pattern family (architectural, concurrency, distributed/enterprise):

1. Deciding whether PideYa is structured as a layered monolith or as microservices.
2. Preventing two threads processing simultaneous payments from corrupting the wallet balance.
3. Making the Order class unaware of the details of the notification channels.
4. Retrying and isolating calls to the external payment service when it degrades.

Solution 1:

1. Behavioral: it is a communication/collaboration problem between objects (notifying changes without coupling).
2. Structural: incompatible interfaces must be made to fit by composing/wrapping existing objects.
3. Creational: the problem is how to build a complex object with many variants.
4. Structural: it is a tree-shaped composition of objects treating parts and wholes uniformly.
5. Creational: coherent families of related objects must be created according to a condition (the country).

Solution 2: in a class-scoped pattern, the relationship is established through inheritance: what behavior each class has is decided at compile time, and an object cannot change its class once created. In an object-scoped one, the relationship is a reference to another object, and a reference can be reassigned at any time. With the example: if we model MotorbikeCourier extends Courier, a courier "is" a motorbike courier forever (we would have to destroy the object and create another). If Courier has a Vehicle, all it takes is courier.assignVehicle(new Bicycle()) mid-shift: the behavior (delivery times) changes on the fly without changing objects.

Solution 3:

1. Architectural: it decides the overall shape of the system, one scale above class design (module 6).
2. Concurrency: coordination of threads and shared state (module 6).
3. GoF: collaboration design between classes inside the application (module 4).
4. Distributed/microservices: resilience against degraded remote services (module 6).

You now have the complete map: two classification axes (purpose and scope), three families with their characteristic question — creational: how are objects born?; structural: how are they composed?; behavioral: how do they collaborate? —, the table of the 23 GoF patterns as a reference index, and the location of the modern families (architecture, concurrency, enterprise, distributed) waiting in module 6. You also know how to read the detail almost everyone overlooks: the class/object axis, which explains why composition dominates the catalog.

Before diving into the first pattern there is one last stop, perhaps the one that brings the most professional maturity: honestly weighing what patterns give and what they cost, and learning to decide when to use them and when not to. It is the lesson that closes this module: Advantages and Disadvantages of Using Design Patterns.