Once you have been doing object-oriented programming for a while, you start to notice that certain problems come up again and again: you need exactly one instance of something to exist, you want to create objects without coupling yourself to their concrete classes, or you need several components to react when something changes. Design patterns are precisely that: proven, named solutions to recurring software design problems. In this lesson you will learn what a design pattern actually is, which elements it is made of, what things are not a pattern (a very common source of confusion), and you will see a first real problem that will serve as motivation. You will also meet PideYa, the project that will accompany us throughout the entire course.

1. The course project: PideYa
2. Definition of a design pattern
3. The four essential elements: context, problem, solution and consequences
4. What a design pattern is NOT
5. How a pattern is described: the pattern template
6. A first motivating look: a real problem in PideYa

Throughout the whole course we will work on a single project: PideYa, a fictional food-delivery ordering platform. The idea is that you do not learn the patterns through abstract ClassA and ClassB examples, but by applying them to a realistic domain that we will grow module by module.

PideYa has the typical ingredients of this kind of application:

• Restaurants with their menu of dishes, prices and opening hours.
• Customers who browse the menus, build a cart and place orders.
• Payments through different gateways (card, PayPal, in-app wallet...).
• Couriers who pick up and deliver the orders.
• Notifications to customers and couriers (email, SMS, push) as the order progresses.

This domain is a gold mine for design patterns: there are complex objects to build (an order with its lines, discounts and delivery address), families of interchangeable objects (payment gateways, notification channels), states that change (an order goes from received to preparing, out for delivery and delivered), and components that need to know what others are doing without becoming coupled to each other. Whenever an example allows it, we will frame it in terms of PideYa.

You do not need to memorize anything about PideYa right now: we will introduce each piece as we need it.

A practical and widely accepted definition is the following:

A design pattern is a general, reusable, named solution to a design problem that appears recurrently in a given context of object-oriented software development.

Let's unpack this definition, because every word matters:

• General solution: the pattern does not solve your specific problem, but the family of problems yours belongs to. That is why it always has to be adapted.
• Reusable: it has been applied successfully many times, in many projects. A trick that only worked once is not a pattern; a pattern is distilled from collective experience.
• Named: this matters more than it seems. Saying "we use an Observer here" communicates in two words a complete structure of classes, responsibilities and collaborations. Patterns create a shared vocabulary among developers.
• Recurring problem: if the problem only appears in your project, the solution may be good, but it is not a pattern.
• In a given context: no pattern is good or bad in the abstract. A pattern is appropriate in its context and counterproductive outside of it.

A useful analogy: a design pattern is to software what a classic recipe is to cooking. The recipe for a Spanish potato omelette tells you the ingredients, the steps and the expected results, but every cook adapts it (with onion or without?). Nobody "copies and pastes" an omelette: they cook it following the pattern.

Every design pattern, whichever it is, is built on four elements. If any of them is missing, you do not have a complete pattern — you only have a fragment of an idea.

Two of them deserve a closer look:

The problem a pattern addresses is never trivial in the sense of "I want to add two numbers". There are always forces in tension: requirements pulling in opposite directions. For example: I want the flexibility to change behavior at runtime (pulling toward more indirection) versus I want simple, direct code (pulling toward fewer classes). The pattern is a documented balance between those forces.

This point separates the professional from the amateur: every pattern has a cost. More classes, more indirection, more concepts the next developer has to understand. A well-applied pattern is one whose benefit clearly outweighs its cost in that context. We will devote the lesson Advantages and Disadvantages of Using Design Patterns to analyzing this in detail.

This is where the most frequent misunderstandings concentrate. Let's clear up the three main ones:

There is no such thing as "the code of the Observer pattern" that you can paste into your project. A pattern describes a structure and a set of responsibilities; the concrete code is something you write each time, adapted to your domain, your language and your constraints. Two correct implementations of the same pattern may not share a single identical line. When you see Java code for a pattern in this course, understand it as one possible materialization, not as the official implementation.

A framework (Spring, Hibernate...) is concrete software that you run; a pattern is knowledge that you apply. The real relationship is the other way around: frameworks are built with patterns. Spring, for example, uses dozens of them internally, which is why understanding patterns makes you a much better framework user: you stop seeing "magic" and start seeing familiar structures.

An algorithm (quicksort, Dijkstra...) solves a computational problem: given an input, it produces an output in a certain number of steps, and its correctness can be proven. A pattern solves a code organization problem: how to distribute responsibilities among classes so the system stays maintainable and extensible. An algorithm is measured in efficiency (time, memory); a pattern is measured in design qualities (coupling, cohesion, extensibility).

Patterns are documented in catalogs, and each pattern is presented using a standardized template. The classic structure (inherited from the Gang of Four catalog, whose history we will cover in the next lesson) includes these sections:

1. Name: short and evocative. It is the piece of vocabulary you will share with your team.
2. Intent: one or two sentences stating what the pattern achieves.
3. Also known as: other names it circulates under.
4. Motivation: a concrete scenario where the problem appears and the pattern solves it.
5. Applicability: signals for when to use it (and, by omission, when not to).
6. Structure: a class diagram with the participants. In this course we will draw them with mermaid, and in the lesson Essential UML for Understanding Patterns you will learn to read them.
7. Participants: each class/interface in the diagram and its responsibility.
8. Collaborations: how the participants interact at runtime.
9. Consequences: benefits and costs.
10. Implementation: tips, variants and pitfalls when turning it into code.
11. Sample code: a materialization in a concrete language.
12. Known uses: where it has been applied in real systems.
13. Related patterns: alternatives and common combinations.

In this course we will use a lightweight version of this template for each pattern in modules 2, 3 and 4: intent, problem in PideYa, structure in mermaid, implementation in Java, consequences and related patterns. Get used to this structure: reading patterns "in template form" is a skill in itself, because professional catalogs (books, company wikis) use this format.

Let's see why all of this matters, with a real problem from PideYa. Note: here we are only going to feel the pain of the problem; the solutions, with their proper names, will arrive in their corresponding lessons.

When an order changes status (for example, the restaurant marks it as "preparing"), several parties need to be informed: the customer via push notification, the assigned courier, and the internal statistics dashboard. A first naive version might look like this:

Let's explain what this code does and why, even though it works, it is a problem waiting to grow:

• The changeStatus method updates the status and then itself creates and calls every interested service: push, SMS and statistics.
• The Order class, which should be concerned with the business logic of an order, knows the details of three systems that are none of its business (how a push is sent, what phone number the courier has, that a statistics dashboard even exists).

Now imagine the typical evolution of the product:

• Marketing asks for an email to be sent as well in certain statuses. → Order has to be touched.
• A loyalty program is added that awards points on delivery. → Order has to be touched.
• In the unit tests for Order, every test sends real SMS messages (and they cost money!) because the services are created with new inside the method. → Hard to test.
• The courier may not be assigned yet → NullPointerException in production.

The underlying problem, in pattern terms, would be:

• Context: a business object whose changes interest a variable number of third parties.
• Problem: the object should not know its interested parties, nor change every time a new one appears; the forces in tension are notify everyone versus be coupled to no one.
• Solution: there is a classic structure that solves exactly this... and it has a name. We will study it in module 4 (Observer). You will also see that creating those services with new is squarely the territory of the creational patterns in module 2.
• Consequences: we will analyze them there, because that solution is not free either.

This is what the course will give you: the ability to recognize these situations, put a name to them and apply the solution distilled by thousands of developers before you, knowing its price.

• Believing that learning patterns means memorizing diagrams. What matters is recognizing the problem and its forces; the structure can be deduced (or looked up) afterwards. If you memorize the solution without the problem, you will apply patterns where they do not belong.
• Searching for "the pattern's code" to copy it. It does not exist. There are examples, like the ones in this course, that you must adapt to your domain. If you copy without adapting, you will end up with generic names (Manager, Handler) that say nothing about your business.
• Confusing a pattern with a framework. If someone says "we use the Spring pattern", concepts are being mixed up. Spring uses patterns; it is not a pattern.
• Wanting to apply a pattern as soon as possible. The urge to "put patterns in" as soon as you learn them is almost universal (and dangerous). First master the problem each one solves; lesson 01-06 and module 5 will give you criteria for deciding.
• Tip: when you read someone else's code (or a framework), practice putting names to the structures you recognize. It is the best possible training and dramatically speeds up code reading.

Think about the following PideYa situation and write out the four elements of a possible pattern (without naming any specific pattern, even if you know one): "The PideYa mobile app must work with three different payment gateways (card, PayPal and in-app wallet), and the sales team is already negotiating with a fourth."

For each item, state whether it can be considered a design pattern and why or why not:

1. The quicksort sorting algorithm.
2. The java.util.logging library.
3. "When several classes share a behavior that varies, extract it into its own hierarchy and inject it, instead of inheriting."
4. A Utils.java file with static methods that your team copies from project to project.

Reread the Order.changeStatus(...) code from this lesson. List at least three "forces" or requirements in tension that make that design problematic, expressing them as pairs of the form "we want X, but we also want Y".

Solution 1 (one possible write-up):

• Context: an ordering application that charges its customers through external payment providers, whose number and variety grows with the business.
• Problem: the charging code must not be rewritten for every new gateway; each gateway has its own API, but the ordering process should treat them uniformly. Forces: uniformity for the code that charges versus the real diversity of the APIs.
• Solution (sketch): define a common "payment" abstraction that the ordering process depends on, and encapsulate the particulars of each provider behind that abstraction, so that adding a gateway means adding a new piece, not modifying the existing ones.
• Consequences: we gain extensibility and the ability to test the charging logic without real gateways; we pay with one more layer of indirection and with the effort of designing an abstraction that fits very different APIs.

Solution 2:

1. No. It is an algorithm: it solves a computational problem with a defined input and output, and it is evaluated by efficiency, not by design qualities.
2. No. It is a library: concrete code that you import and run. (Internally it applies patterns, but it is not one itself.)
3. Yes (or at least it has the shape of one): it describes a recurring problem, a general solution in terms of structure and responsibilities, and it is adaptable to many contexts. In fact, it points to a principle we will see in 01-03: favor composition over inheritance.
4. No. It is copy-pastable code, exactly what a pattern is not. It may be useful, but it describes no problem, context or consequences: it is just a concrete implementation that travels between projects.

Solution 3 (three valid examples; there are more):

• We want every interested party to learn about the status change, but we also want Order to know none of them.
• We want to add new notifications (email, loyalty) easily, but we also want to avoid modifying Order each time.
• We want to test Order with unit tests, but we also want production to use the real SMS and push services (and with new inside the method, there is no way to substitute them in tests).

In this lesson we have laid the foundations of the course: a design pattern is a named, proven and adaptable solution to a recurring problem, always described through four elements (context, problem, solution and consequences) and documented in standardized templates. Just as important is what a pattern is not: not copy-pastable code, not a framework, not an algorithm. And with the PideYa notification problem you have already seen the kind of situation patterns solve: code that works today but degrades with every new requirement.

You may be wondering where this idea of cataloging named solutions came from. The answer is a curious story that begins, of all places, in building architecture. That is the subject of the next lesson: History and Origin of Design Patterns.