Description and comparison

Design patterns are reusable solutions to problems that occur frequently in software design. They are not finished pieces of code you paste in — they are blueprints, templates for solving a class of problem. A pattern describes the problem, explains why naive solutions fail, and gives you a proven structure that works. Patterns emerged from Christopher Alexander's architecture work and were brought into software by the "Gang of Four" (Gamma, Helm, Johnson, Vlissides) in their 1994 book "Design Patterns: Elements of Reusable Object-Oriented Software".

A pattern is not an algorithm. An algorithm defines an exact sequence of steps. A pattern is a high-level description of a solution — the same pattern can be implemented differently in different languages and contexts.

Why Patterns Matter

The Three Categories

The Gang of Four classified all 23 patterns into three categories based on their purpose. Creational patterns handle object creation. Structural patterns handle how objects are composed into larger structures. Behavioural patterns handle communication and responsibility between objects. Understanding which category a pattern belongs to immediately tells you what problem it is solving.

Creational Patterns at a Glance

Creational — Object Creation

Creational patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. Instead of calling constructors directly, you go through an interface — a factory method, a factory object, a builder, a clone, or a static accessor. This gives you flexibility to change what gets created, how it gets created, and when it gets created, without touching client code. As systems grow, object creation becomes a non-trivial concern: you may need to pool objects, ensure uniqueness, support multiple representations, or defer costly construction. Creational patterns address all of these.

Factory Method

Abstract Factory

Builder

Prototype

Singleton

Structural Patterns at a Glance

Structural — Object Composition

Structural patterns are concerned with how classes and objects are composed to form larger structures. Class-based structural patterns use inheritance to compose interfaces. Object-based structural patterns describe ways to compose objects to realise new functionality. The key insight is that flexible designs often arise not from inheritance hierarchies, but from how objects reference and delegate to each other. Structural patterns let you assemble objects into novel structures without rewriting the classes involved. They are especially valuable when integrating third-party libraries, building layered architectures, or optimising memory for large object graphs.

Adapter

Bridge

Composite

Decorator

Facade

Flyweight

Proxy

Behavioural Patterns at a Glance

Behavioural — Object Communication

Behavioural patterns characterise the ways in which classes or objects interact and distribute responsibility. They shift your focus from structure to communication: who sends messages to whom, in what order, and who handles what. Many of these patterns decouple senders from receivers — the sender does not know who will handle a request, or even if anyone will. Others encapsulate algorithms so they can be swapped at runtime, or record and restore object state. Behavioural patterns are where most of the day-to-day design decisions happen: how events flow through the system, how requests are dispatched, how state machines are modelled, and how undo functionality is implemented.

Chain of Responsibility

Command

Iterator

Mediator

Memento

Observer

State

Strategy

Template Method

Visitor

All 23 Patterns: The Full Timeline

Comparing Patterns That Are Often Confused

Several patterns share surface-level similarities — they both wrap objects, or they both define interfaces — but solve fundamentally different problems. The following comparisons clarify the intent behind each pair or group.

Factory Method vs Abstract Factory vs Builder

Adapter vs Decorator vs Proxy

Strategy vs State vs Template Method

Observer vs Mediator vs Chain of Responsibility

Composite vs Decorator

Design Principles Behind the Patterns

The Principles Patterns Apply

Patterns are not invented arbitrarily — each one is a direct application of one or more foundational design principles. Understanding the principle behind a pattern helps you recognise when to apply it and when a simpler solution is better. The Gang of Four identified two key principles that underpin almost all 23 patterns: 'Program to an interface, not an implementation' — which enables all the polymorphic flexibility — and 'Favour object composition over class inheritance' — which avoids the fragile base class problem and enables runtime flexibility. From these two principles, plus SOLID (especially OCP and DIP), the entire pattern catalogue follows naturally.

Program to interfaces

Favour composition

Open/Closed Principle

Dependency Inversion

Single Responsibility

Liskov Substitution

Don't Repeat Yourself

When NOT to Use Patterns

Patterns in Modern Java Frameworks

Where You See Patterns Every Day

Design patterns are not academic exercises — they are the invisible scaffolding of every major Java framework and library you use. Spring Framework is a pattern showcase: its IoC container is Dependency Injection (a variant of Strategy + Factory), @Transactional uses dynamic Proxy, @Async uses Proxy, ApplicationEvent uses Observer, RestTemplate uses Template Method, and Spring MVC's DispatcherServlet uses Chain of Responsibility for handler mapping. Hibernate uses Proxy for lazy-loaded entities, Identity Map (Flyweight-like) for session cache, and Repository (Facade) for database access. The java.io package is built entirely on Decorator (InputStream wrappers). JDBC uses Bridge between the standard API and vendor implementations. JavaFX and Swing use Composite for the component tree and Observer for event listeners. Knowing patterns is knowing how frameworks work — not just how to call their APIs.

Spring IoC

@Transactional Proxy

ApplicationEvent

Hibernate Proxy

java.io Decorator

JDBC Bridge

Swing Composite

Click highlighted lines to spot the pattern inside Spring + Java SE

java

// ── Observer ─────────────────────────────────────────────────────

@EventListener

▼

public void onOrderPlaced(OrderPlacedEvent event) { ... }

// ── Proxy (@Transactional) ───────────────────────────────────────

@Transactional

▼

public void transferFunds(Account from, Account to, BigDecimal amount) { ... }

// ── Template Method ──────────────────────────────────────────────

JdbcTemplate.query(sql, rowMapper);

▼

// ── Decorator (java.io) ──────────────────────────────────────────

new BufferedReader(new InputStreamReader(socket.getInputStream()));

▼

// ── Strategy ─────────────────────────────────────────────────────

list.sort(Comparator.comparing(Person::getName));

▼

Key takeaway: Design patterns are a language — a vocabulary for design decisions. Mastering them does not mean memorising 23 class diagrams. It means understanding the problems they solve, recognising those problems in your own code, and knowing when the pattern's benefits outweigh its costs.

What's next: the following chapters cover each pattern in depth — with interactive diagrams, full code examples, and real-world Java library references. Start with Creational Patterns, then move to Structural, then Behavioural. Each lesson builds on the vocabulary introduced here.