What are design patterns?

A design pattern is a reusable solution to a problem that comes up again and again when designing software. It isn’t an algorithm (an exact recipe of steps) or a library (code you import and use as-is), but something in between: a way of structuring classes and objects that solves a recurring problem, and that you have to adapt to each concrete case. Nobody “installs” the Observer pattern; you implement it, with names and details specific to each project, following a general shape that’s already known to work.

That general shape didn’t come out of nowhere: in 1994, four authors — known ever since as the “Gang of Four” (GoF) — published a catalog of 23 patterns they’d seen recur in well-designed object-oriented systems. That catalog, with slight variations, is still the standard reference.

Why they’re worth knowing

• They’re proven solutions. When you use a known pattern, you aren’t inventing a new solution to a design problem — you’re applying something that has been validated across thousands of different projects. That reduces the margin for error in decisions that, made badly, are expensive to reverse later.
• They give you shared vocabulary. Saying “this needs a Strategy” communicates a complete design intent in three words to another developer who knows the catalog. Without that vocabulary, the same idea means explaining the whole structure every time.
• They make a future change possible without touching code that already works. Most patterns exist so that one kind of change (adding a new type of product, a new export format, a new business rule) gets resolved by adding new code, not by modifying code that already works and has already been tested.

Not every problem needs a pattern

Patterns aren’t a goal in themselves. Dropping a pattern in where it isn’t needed adds indirection, files, and layers that someone later has to understand — sometimes the simplest solution is to use no pattern at all. The useful question isn’t “can I use a pattern here?” but “has someone already solved this specific problem in a recognizable way?”. Each pattern’s article includes a section on when it’s worth it and when it isn’t, exactly for that.

The three categories

The catalog is organized into three groups, by the kind of problem they solve:

• Creational patterns — about how objects get created, so the code isn’t tied to concrete classes.
• Structural patterns — about how classes and objects combine into larger structures while staying flexible and efficient.
• Behavioral patterns — about how responsibilities are divided among objects and how they communicate with each other.
• Design patterns that are often confused — some patterns have similar structures but solve different problems: what sets them apart and how to recognize when to use each.

The domain of the examples

The code examples in this topic are in Java, and almost all of them share one fictional case: AndesShop, an e-commerce store selling clothing and trekking gear that keeps growing and runs into different design problems as it adds features.

AndesShop is the same business whose payments module the software architecture topic uses as its example: there it’s viewed from the outside, deciding the boundaries between services, what data each one shares, and how they communicate; here it’s viewed from inside a class. That’s deliberate: design patterns and architecture decisions operate on the same system, at different scales.

Relationship with design principles

A pattern isn’t an alternative to the design principles, it’s a concrete application of several of them at once. Strategy is Open/Closed made structural; Decorator is composition over inheritance taken to its limit; almost all of them push the dependency toward an abstraction, which is dependency inversion.

That’s why it’s worth reading the principles before the catalog: patterns make a lot more sense once you know which design tension they’re resolving.