Java Design Patterns: Overview
Design patterns are reusable solutions to common software design problems. They provide proven approaches that improve code maintainability, readability, and scalability, while establishing a shared vocabulary for developers to communicate design decisions.
Design Patterns Quick Reference
| Pattern | Category | Complexity | Popularity |
|---|---|---|---|
| Abstract Factory | Creational | βββ (2/3) | βββ (3/3) |
| Adapter | Structural | βββ (1/3) | βββ (3/3) |
| Bridge | Structural | βββ (3/3) | βββ (1/3) |
| Builder | Creational | βββ (2/3) | βββ (3/3) |
| Chain of Responsibility | Behavioral | βββ (2/3) | βββ (2/3) |
| Command | Behavioral | βββ (1/3) | βββ (3/3) |
| Composite | Structural | βββ (2/3) | βββ (2/3) |
| Decorator | Structural | βββ (2/3) | βββ (2/3) |
| Facade | Structural | βββ (1/3) | βββ (2/3) |
| Factory Method | Creational | βββ (1/3) | βββ (3/3) |
| Flyweight | Structural | βββ (3/3) | βββ (1/3) |
| Interpreter | Behavioral | βββ (3/3) | βββ (1/3) |
| Iterator | Behavioral | βββ (2/3) | βββ (3/3) |
| Mediator | Behavioral | βββ (2/3) | βββ (2/3) |
| Memento | Behavioral | βββ (3/3) | βββ (1/3) |
| Observer | Behavioral | βββ (2/3) | βββ (3/3) |
| Prototype | Creational | βββ (1/3) | βββ (2/3) |
| Proxy | Structural | βββ (2/3) | βββ (1/3) |
| Singleton | Creational | βββ (1/3) | βββ (2/3) |
| State | Behavioral | βββ (1/3) | βββ (2/3) |
| Strategy | Behavioral | βββ (1/3) | βββ (3/3) |
| Template Method | Behavioral | βββ (1/3) | βββ (2/3) |
| Visitor | Behavioral | βββ (3/3) | βββ (1/3) |
The Three Categories
| Category | Purpose | Patterns Covered |
|---|---|---|
| Creational | Control how objects are created | Singleton, Factory Method, Abstract Factory, Builder, Prototype |
| Structural | Manage object composition & relationships | Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy |
| Behavioral | Define how objects communicate & share responsibility | Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor |
Creational Patterns at a Glance
| Pattern | Complexity | Popularity | Intent | Key Mechanism |
|---|---|---|---|---|
| Abstract Factory | βββ (2/3) | βββ (3/3) | Provide an interface for creating families of related objects without specifying their concrete classes. | Factory of factories |
| Builder | βββ (2/3) | βββ (3/3) | Separate the construction of a complex object from its representation, allowing the same construction process to create different representations. | Fluent builder with build() |
| Factory Method | βββ (1/3) | βββ (3/3) | Define an interface for creating objects, but let subclasses decide which class to instantiate. | Factory method returns interface type |
| Prototype | βββ (1/3) | βββ (2/3) | Create new objects by cloning an existing instance (prototype) rather than constructing from scratch. | clone() method |
| Singleton | βββ (1/3) | βββ (2/3) | Ensure a class has only one instance and provide a global point of access to it. | Private constructor + static accessor |
Structural Patterns at a Glance
| Pattern | Complexity | Popularity | Intent | Key Mechanism |
|---|---|---|---|---|
| Adapter | βββ (1/3) | βββ (3/3) | Convert the interface of a class into another interface clients expect, allowing incompatible interfaces to work together. | Wraps adaptee, implements target |
| Bridge | βββ (3/3) | βββ (1/3) | Decouple an abstraction from its implementation so that the two can vary independently. | Composition linking two hierarchies |
| Composite | βββ (2/3) | βββ (2/3) | Compose objects into tree structures to represent part-whole hierarchies, and treat individual objects and compositions uniformly. | Component interface for leaf + composite |
| Decorator | βββ (2/3) | βββ (2/3) | Attach additional responsibilities to an object dynamically, providing a flexible alternative to subclassing for extending functionality. | Wraps object, extends same interface |
| Facade | βββ (1/3) | βββ (2/3) | Provide a simplified, unified interface to a complex subsystem. | High-level wrapper methods |
| Flyweight | βββ (3/3) | βββ (1/3) | Use sharing to support large numbers of fine-grained objects efficiently. | Flyweight pool returning existing instances |
| Proxy | βββ (2/3) | βββ (1/3) | Provide a surrogate or placeholder for another object to control access to it. | Same interface, intercepts requests |
Behavioral Patterns at a Glance
| Pattern | Complexity | Popularity | Intent | Key Mechanism |
|---|---|---|---|---|
| Chain of Responsibility | βββ (2/3) | βββ (2/3) | Pass a request along a chain of handlers. Each handler decides to process the request or pass it to the next handler. | Linked handlers with next reference |
| Command | βββ (1/3) | βββ (3/3) | Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. | Command object with execute()/undo() |
| Interpreter | βββ (3/3) | βββ (1/3) | Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. | Syntax tree of rule expressions |
| Iterator | βββ (2/3) | βββ (3/3) | Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation (list, stack, tree, etc.). | Iterator interface with hasNext()/next() |
| Mediator | βββ (2/3) | βββ (2/3) | Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. | Mediator interface coordinates colleagues |
| Memento | βββ (3/3) | βββ (1/3) | Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. | Memento stores internal state snapshot |
| Observer | βββ (2/3) | βββ (3/3) | Define a one-to-many dependency so that when one object changes state, all its dependents are notified and updated automatically. | Subject maintains observer list |
| State | βββ (1/3) | βββ (2/3) | Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. | State classes encapsulate context behaviors |
| Strategy | βββ (1/3) | βββ (3/3) | Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. | Composition with strategy interface |
| Template Method | βββ (1/3) | βββ (2/3) | Define the skeleton of an algorithm in a superclass, letting subclasses override specific steps without changing the algorithm's structure. | Abstract class with final template method |
| Visitor | βββ (3/3) | βββ (1/3) | Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. | Double dispatch pattern |
Design Patterns vs Design Principles
| Concept | What It Is | Examples |
|---|---|---|
| Design Principle | General guideline for writing good code | SOLID, DRY, KISS, YAGNI |
| Design Pattern | Specific, proven solution template for a recurring problem | Singleton, Factory, Observer |
Patterns often implement one or more principles β for example, the Strategy pattern applies the Open/Closed Principle and Dependency Inversion.
When to Use Design Patterns
- DO use patterns when you recognize a recurring design problem they solve
- DO use patterns to communicate intent clearly with your team
- DON'T force patterns into every problem β simplicity beats cleverness
- DON'T over-engineer with patterns when a straightforward solution works
"Design patterns should be used to simplify code, not to complicate it."
Advanced Editorial Pass: Pattern Selection Under Real Constraints
Architectural Decision Heuristics
- Start with volatility analysis: which part of the design is likely to change first (creation, composition, or behavior)?
- Select the lightest pattern that isolates that volatility; avoid introducing extension points with no credible change pressure.
- Evaluate operational impact early: observability, failure isolation, and debugging complexity matter as much as class design elegance.
Common Misuse Signals
- A pattern is chosen before a concrete pain point exists.
- Teams use pattern names as status signals instead of problem-solution language.
- The implementation increases indirection but does not reduce coupling or change risk.
Senior-Level Review Questions
- Which design axis are we trying to stabilize: construction, structure, or runtime behavior?
- What is the expected cost of removing this pattern in 6 months if requirements simplify?
- Does this pattern improve deploy-time and run-time operability, or only source-level aesthetics?