Design Patterns
A design pattern is not a library you import and call. It is a named, reusable solution template for a recurring problem: a proven idea you adapt to your own code by hand. A pattern's value is that it has a name: saying "we need a factory here" hands a colleague an entire solution in two words.
The Gang of Four (GoF) splits patterns into three families: creational — about creating objects, structural — about how objects are composed, and behavioral — about how objects interact and share responsibility. This topic covers the three most-asked creational patterns — Singleton, Factory, and Builder — and the layers below give the full map.
Topic map
- Design Patterns — what a pattern is (a template, not a library) and the three GoF categories with examples.
- Singleton — exactly one instance and a global access point; how to make lazy initialization thread-safe.
- Factory Method — object creation delegated to a method that returns an interface; the client decoupled from concrete classes.
- Builder — step-by-step construction through a fluent API instead of telescoping constructors.
Common traps
| Mistake | Consequence |
|---|---|
| Treating a pattern as ready-made code to import | You copy someone's class instead of adapting a template — then fight name and context mismatches |
Filing Factory under structural patterns | Category confusion: factory is a creational pattern (about object creation), not composition |
A lazy Singleton without synchronization | Two threads race past the == null check and each create an instance — the single-instance guarantee is broken |
Forgetting volatile in double-checked locking | Another thread sees a partially constructed object (the reference is assigned before the fields are initialized) |
| Leaving the built object mutable | The main benefit of Builder — an immutable result — is lost |
A Builder for a trivial two-field object | Needless indirection; a plain constructor is clearer and shorter here |
Interview relevance
Patterns are not asked as memorised UML diagrams but as a check of whether you understand which problem each pattern solves, what its traps are, and when plain code is simpler. A candidate who says "a singleton is one instance, and here are three ways to make it thread-safe" immediately stands out from "well, it's when there's one object".
Typical checks:
- The three GoF categories and what each solves; why a pattern is a template, not a library.
Singleton: the single-instance guarantee and how to make lazy initialization thread-safe (enum, static holder, double-checked locking onvolatile).Factory: how returning an interface decouples the client from concrete classes.Builder: the telescoping-constructor problem and its link to immutable objects.- When a pattern is NOT needed — where plain code is simpler.
Common wrong answer: "A pattern is a ready-made class from the standard library that you import and call." That opens a discussion of a pattern being a template you adapt to context, not copy-paste code, and of over-using patterns (bolting them on where plain code suffices) being a mistake too.