Design patterns — cheat sheet

General OOP-design knowledge, no course slide source — written directly, same as 12-solid-principles.md. A handful of the patterns most likely to come up at junior/mid level, kept to what each one is, when to reach for it, and where it already shows up in material covered so far (Spring specifically rewards recognizing these).

Strategy

Define a family of interchangeable algorithms/behaviors behind one common interface, and let the calling code pick (or be handed) which one to use at runtime.

Already built, without naming it yet: the RandomNumberGenerator interface with SimpleRandomNumberGenerator and MockRandomNumberGenerator as interchangeable implementations — see 10-dependency-injection.md. That whole exercise is the Strategy pattern.

Singleton

Ensure a class has exactly one instance, with a single global access point to it.

Relevant directly to Spring: beans are singleton-scoped by default — the Application Context creates one instance of a @Service/@Repository/etc. and hands that same instance to everyone who needs it injected, unless you explicitly configure a different scope. Worth mentioning this connection if asked about Singleton in a Spring-focused interview — it's not just a textbook pattern, it's the default behavior underpinning Spring's dependency injection.

Factory (Factory Method / Simple Factory)

Put object-creation logic behind a method/class instead of scattering new ConcreteClass(...) calls throughout the codebase — the caller asks for "a thing that satisfies X" and gets back a concrete instance without needing to know which concrete class was chosen or how it was built.

Useful when: which concrete class to instantiate depends on some condition (config, an enum, input data), and you don't want that decision duplicated everywhere an instance is needed.

Builder

Construct a complex object step by step via chained method calls, instead of one constructor with a long list of (often optional) parameters.

java

Pizza pizza = new Pizza.Builder()
        .size("large")
        .topping("mushroom")
        .topping("olives")
        .build();

Useful when a class has many optional fields — avoids "telescoping constructors" (a constructor overload for every combination of optional args) and avoids ambiguous calls like new Pizza(true, false, null, 12). Directly relevant here: Lombok's @Builder annotation generates exactly this pattern for you — another reason Lombok showed up early in the Spring Boot material.

Observer

An object (the subject) maintains a list of dependents (observers) and notifies them automatically when its state changes, without needing to know what each observer actually does with that notification.

Everyday example: a GUI button's click listeners, or a pub/sub event system. Less central to a Spring Boot REST backend than the other patterns above, but a common enough "have you heard of this" interview question to recognize by name and shape.

Interview framing

At this level, expect "have you heard of the X pattern, what does it do" more than "go implement X pattern from scratch." Recognizing Strategy and Singleton specifically as things already sitting inside the Spring/DI material covered is stronger than reciting a textbook definition cold.

Design patterns — cheat sheet ​

Strategy ​

Singleton ​

Factory (Factory Method / Simple Factory) ​

Builder ​

Observer ​