Use this compact Java pattern cheat sheet to recall when a pattern helps, what pressure it addresses, and what common misuse to watch for.
This cheat sheet is for quick recall, not for first learning. Each row is a reminder of the real design pressure behind the pattern.
| Pattern | Reach for it when | Main misuse to watch for |
|---|---|---|
| Factory Method | callers need a stable creation contract while concrete choice varies | hiding simple constructor logic behind unnecessary indirection |
| Abstract Factory | related product families must vary together | creating a full family abstraction when only one product varies |
| Builder | object construction is noisy, staged, or validation-heavy | building trivial objects with ceremonial builders |
| Prototype | a configured object should produce meaningful copies | unclear copy semantics or accidental state sharing |
| Singleton | one process-wide instance is genuinely part of the model | disguised global state |
| Strategy | behavior must vary cleanly without large conditionals | exploding the number of tiny strategies with no meaningful difference |
| Observer | many listeners must react to one source of change | event storms and unclear lifecycle management |
| Command | actions should be first-class, queueable, undoable, or auditable | wrapping simple method calls for no real gain |
| State | behavior changes with lifecycle state | replacing simple conditional logic with unnecessary class explosion |
| Adapter | incompatible interfaces must collaborate | adding wrappers when the code could simply be redesigned directly |
| Facade | a subsystem needs a simpler entry point | turning the facade into an omniscient god object |
| Proxy | access needs control for laziness, remoting, or protection | confusing access control with extra behavior decoration |
If a pattern choice feels uncertain, look at the “misuse” column first. In Java, misapplied patterns often fail not because the pattern is unknown, but because the real design pressure was named incorrectly.